search

mathjazz / pontoon

In-place localization tool
https://pontoon.mozilla.org/
BSD 3-Clause "New" or "Revised" License
3 stars 1 forks source link

[Translate.Next] Put l10n files next to components #1161

Open mathjazz opened 5 years ago

mathjazz commented 5 years ago

This issue was created automatically by a script.

Bug 1504710

Bug Reporter: @adngdb CC: @stasm

In our current structure, each component has a bunch of files, in most cases: Component.js (contains the code), Component.test.js (tests) and Component.css (styling). It would be pretty great if we could add Component.ftl to that list, so that translation files leave just next by their associated component, just like the rest.

There are a bunch of questions to answer around that.

(1) means we add a build step every time we make a change to translations. That might be part of the JS build step. It will probably require some code, to make that work with our workflow (webpack). It will also probably require configuration so that it's possible to merge translations into different files, etc.

This solution requires code, but has the highest impact because it will potentially be useful to future users of Fluent with React.

(2) means that localizers have a lot of files to translate (one per component) and that we will ship several FTL files per component to clients loading the web app. However that means the client will only download the translations that are actually needed, just when needed, instead of loading the entire list of translations. It is, however, very probable that this is a very negligible gain.

This solution requires less code, but might be more painful for localizers and clients.

There might be other solutions but I could not come up with them while thinking about this for now.

mathjazz commented 5 years ago

Comment Author: @Pike

Dedicated files also provide context to the strings. It also allows the IDs to be smaller, which might make them more human readable.

Localizers wanting the full list can just use the all-resources link in Pontoon.

I'm not a fan of having tools in the path between developers and l10n workflow.

I'd go for files per component.

mathjazz commented 5 years ago

Comment Author: @stasm

In the approach #2, would you need (or want) to cache already-fetched FTL files for later use? Suppose the EntityDetails component has its own FTL file. Can we rely on the browser's cache and just fetch this file plenty of times, or would we want to create a caching layer (probably in the L10nAPI class)?

mathjazz commented 5 years ago

Comment Author: @adngdb

With (2), we could ship the en-US translation with each component by default, in the JS bundle. Then we'd only need to fetch one FTL file per component in most cases, sometimes 2, I guess max 3? We would of course need to set some cache. There's going to be a service worker at some point, we'll probably use that.

The question I can't answer yet at this point is, how to we know what files to download, and when do we do that. We could potentially based all components on a mother-component that, on mount, downloads its FTL files for each locale. However, I'm not sure that's even possible. I guess the best way to figure this out is to prototype it.