Building a gettext to fluent converter

Fluent
#1

Hi,

I’m a skunkworks coder at a for-profit company. Our entire app, dev environment and stack is built on open source (Debian, postgres, python, node, git etc).

We want to go all-in on Fluent as a massive upgrade to our localization. We would like to convert our existing gettext translations to ftl. Any thoughts on what this would take?

Could we help the Moz community and ourselves at the same time by providing the developer time to build a conversion script, perhaps as part of fluent-migrations?

We are ok that the resulting ftl may need hand tweaking beyond what a tool can do, because ftl is more expressive than gettext. We just seek to automate as much of the work as possible, so we can move existing translations out of .po files (which in our case are quite numerous) and into .ftl format where they can be improved on, and eventually instrumented thru Pontoon.

I confess I don’t really understand the separation of concerns between the Fluent sub-projects. I don’t know what moving parts are specific to Mozilla project structures vs more general. If fluent-migrations is one of the former, then we can look at other ways e.g. yacc scripts.

If there’s any interest, as I said we can donate the dev-hours. I would just need some advice on how to get started, e.g which parts of the fluent-migrations API we should start with in order to have a hello world converter that we can iterate on. Or if there is a better part of the codebase to leverage. I’m not averse to reading loads of code and working with undocumented APIs. But early decisions about where to begin from the veterans will be a big help in making sure I don’t make any false starts (or at least, not too many :-))

Kia kaha from New Zealand.

#2

I revisited this github issue and managed to hack one of the mentioned URLs so it didn’t 404. That led me to some Firefox docs about the fluent-migrations project that look more detailed than anything I’ve found so far.

I’ll continue posting progress if I make any headway.

#3

It seems that fluent-migrations as used by the FF team is geared for piecemeal migrations (evolving the code base towards Fluent rather than doing it all in one chunk). I like this approach, it spreads the cost of shifting away from gettext, makes the converters so specific to each case as to be trivial, and means there are human eyes on each string as it’s migrated.

Not sure yet how this works across multiple locales, but still reading the docs.

#4

Making sense now. Each recipe describes a migration for specific strings across all locales defined in the legacy format(s).

This is gonna work.

#5

Hi Julian,

seems you found one of the answers to your email :wink: .

Since the issue that you found, there’s been another project that we convert, and I think that process is closer to what you’re looking for.

https://bedrock.readthedocs.io/en/latest/fluent-conversion.html has the docs on that.

There’s one kink with gettext support in compare-locales, they localization keys are tuples, and not plain strings. I didn’t have a better idea for contexts. That’s not a problem per se, but it does mean that you can’t easily use transforms_from, and you’ll want to create regular AST-based migration recipes. You’ll end up with snippets like

po_src = "messages.po"
...
COPY(po_src, ("my original text", None))
1 Like
#6

Hiya. Thanks for your help! I will look into this now and report back.