fluent ftd

[amitu]

We need an ability for people to translate components. FPM has basic support for translation. Ftd needs fluent like syntax to define parametrisable translation messages.

Project Fluent Overview

Project Fluent by Mozilla is a format for storing translations. Example .ftl file:

tabs-close-button = Zamknij
tabs-close-tooltip = {$tabCount ->
    [one] Zamknij kartę
    [few] Zamknij {$tabCount} karty
   *[many] Zamknij { $tabCount } kart
}
tabs-close-warning = {$tabCount ->
    [few] Zostaną zamknięte {$tabCount} karty.
          Czy chcesz kontynuować?
   *[many] Zostanie zamkniętych {$tabCount} kart.
           Czy chcesz kontynuować?
}

They define named "messages", here tabs-close-warning is a message. And message definition can use "data", eg here they are using $tabCount.

They have a match syntax, $tabCount -> [few] Few messages [many] many messages. While the $tabCount is an integer, they have special matching rules for few, many etc. These are called "selectors":

The selector may be a string, in which case it will be compared directly to the keys of variants defined in the select expression. For selectors which are numbers, the variant keys either match the number exactly or they match the CLDR plural category for the number. The possible categories are: zero, one, two, few, many, and other. For instance, English has two plural categories: one and other.

So they have variable substitution and selectors. They have other stuff like attributes, and functions.

We Can Not Use Fluent

Can't we just use Fluent?

Two Languages

Fluent is great, but is not compatible with ftd. We already have quite a few things, variables, substitutions etc. We want to implement "case/match" statement in ftd. We are going to have our own functions.

So if we allow fluent as is in FTD, we will have duplicate concepts.

How About We Do .ftl Support?

What if we do not mix fluent syntax in ftd, but instead allow people to store .ftl file in fpm package itself. FTD will not technically need any extension, match can wait for example. But whenever the feature is ready, we will forever have a dependency on fluent, have to teach two different syntax, and accept the impedance mismatch.

Question Of Frontend

These translations must happen on frontend as well. When we are building function support in FTD, we are going to ensure the functions that are needed from frontend are somehow sent along with HTML to frontend as well, so they can be evaluated. What set of fluent would have to be sent to frontend to make the whole thing seamlessly work?

Everything Provided By Fluent Is Needed Without Translation As Well

Virtually everything ftl does, we can do in plain ftd, and we want to do it for even other reasons, like we want to create such string functions, even we do not need translation. We will need to support function, we will need the match expression, the variable interpolation. If we have implemented all these, then what is left? Why do we still need another relatively heavy dependency, with a learning curve beyond ftd?

How Could FTD Emulate Fluent?

Lets try to rewrite the example above in ftd:

;; this is just a string variable
-- string tabs-close-button: Zamknij

;; this is a function that returns string
-- string tabs-close-tooltip:
integer tabCount:  ;; explicitly defined arguments

match ftd.i18n.plural_forms(tabCount) {
    "one" => "Zamknij kartę"
    "few" => "Zamknij {$tabCount} karty"  ;; strings can do variable interpolation
    * => "Zamknij { $tabCount } kart"
}

-- string tabs-close-warning:
integer tabCount:   

match ftd.i18n.plural_forms(tabCount) {
    "few" => "Zostaną zamknięte {$tabCount} karty.
          Czy chcesz kontynuować?"  ;; multi line strings
    * =>  "Zostanie zamkniętych {$tabCount} kart.
           Czy chcesz kontynuować?"
}

How Will Translation Work?

fpm has support for translation. If a package is translated, every time you import that package, the corresponding package in your preferred language is actually used transparently. So if fpm package djangoproject.com is translated in Spanish djangoproject.com/es, and any module imports djangoproject.com/messages, they end up importing djangoproject.com/es/messages, and in both you have tags-close-warning defined, with same type/signature.