quickwrite / fluent4j

A Java library that implements Mozilla Fluent

fluent4j

A Java library that implements Mozillas Fluent project.

Installation

Maven

<repositories>
    <repository>
        <id>quickwrite-net-fluent4j</id>
        <url>https://dl.cloudsmith.io/public/quickwrite-net/fluent4j/maven/</url>
    </repository>
</repositories>

<dependencies>
    <dependency>
        <groupId>net.quickwrite</groupId>
        <artifactId>fluent-builder</artifactId>
        <version>{{package-version}}</version>
    </dependency>
</dependencies>

Gradle

repositories {
    maven {
        url "https://dl.cloudsmith.io/public/quickwrite-net/fluent4j/maven/"
    }
}

dependencies {
    implementation 'net.quickwrite:fluent-builder:{{package-version}}'
}

What is fluent4j?

The fluent4j library is a Java implementation of Mozillas Fluent project that intends to be extensible by default.

This means that custom constructs can be added to the basic fluent syntax so that the translation files can be used for the projects exact needs.

Usage

So that the translation files can be used the files need to be parsed first:

ResourceParser resourceParser = ResourceParserBuilder.defaultParser();

FluentResource resource = resourceParser.parse(FluentIteratorFactory.fromString("""
test = This is your fluent file

emails = You have { $unreadEmails } unread emails.
"""));

After you've created a single or multiple Resources you can bundle them in a Bundle with other data for use:

FluentBundle bundle = FluentBundleBuilder.builder(Locale.ENGLISH)
                                         .addResource(resource)
                                         .build();

And now you can use the different messages for translation:

System.out.println(bundle.resolveMessage("test", StringResultFactory.construct()).get());

This is your fluent file

And you can also provide arguments for the messages:

FluentArguments arguments = ArgumentListBuilder.builder()
                                               .add("unreadEmails", 5)
                                               .build();

System.out.println(bundle.resolveMessage("emails", arguments, StringResultFactory.construct()).get());

You have 5 unread emails.

License

This project is licensed under the permissive Apache 2.0 license.

fluent4j's Issues

Add JavaDocs

Add JavaDocs to the API so that the API can be a lot more easily understood.

Better Error handling

With the current implementation the parser is completely stopping when it finds an error. This can be quite cumbersome as sometimes you have multiple errors in the same file which means that you need to parse it, find the errors and parse it again (and do the same thing multiple times).

It would be a lot easier if the error handling would work so that all of the errors are being reported.

The problem with this is of course that when an error is being detected the parser must be able to "recover" from this error so that it does not spit out thousands of errors as it still tries to parser the file in a specific way.
Maybe it would be sensible to create a custom error handler for a parser and when it detects an error it is correctly handling the situation.

Add correct documentation in README.md

The README currently has incorrect documentation where the API that is being shown is an old version of it.

Add tests for the new fluent implementation

Tests should be added to the library to ensure that the library works as intended and there are no unwarranted side-effects.

Speed up Numbers

It seems like numbers themselves are quite slow. This should be fixed.

Implement Custom API in Interfaces

Currently the API that exists is a mixture of Classes and Interfaces.
But the user should not be using any Class, Method, etc. that is in the impl package.

This means there should be some builders in the interfaces.

Infinite Recursion leads to Crash

When the fluent message contains some infinite recursion the entire java program will crash.

For example:

message = { message }

In this case the program will just access itself and crash.

---

This could be fixed by checking if a term/ message has already been accessed and if this is true it will fail.

It could also be done at the parsing step by walking over the tree and checking if this is the case.