3 ms·
I think that storing the localized content in separate flat HTML files makes it very difficult to maintain translations, as the article points out. Ideally, yo
by pavon 6y ago
I think that storing the localized content in separate flat HTML files makes it very difficult to maintain translations, as the article points out.
Ideally, you would have a master document in which some parts are shared across all translations (like the layout, the actual terms in the spec, browser compatibility information, etc), while other parts were localizable (like the field descriptions). Then when content was added/changed, it would be clear which parts of the translations needed updating, and you could either flag them as such for volunteers, or use machine translation as a stop-gap, or both.
With the architecture they described, however, your options are either to make the translations completely independent or to make translations completely machine translated, neither of which is a good solution.
- Cthulhu_ 6y agoIt's quite telling already that they basically admit that mixing markup and content as tightly as that is problematic. I mean I don't think it's actually that big of a deal as long as they stick to basic HTML markup (paragraphs, bold/italics, etc), but you're already running into problems when you add links. Not having multi-language support as a first-class citizen is a step backwards IMO. Especially considering the world is still getting connected at an enormous rate.
- afiori 6y agoMulti-language support has the inherent problem that is requires effort linearly in the number of languages. Wearing a hopeful hat this new architecture would only require an effort "linear" to the error rate of the machine translations. Personally I had some very good experiences with some translators, and it could work even better if Mozilla manages to tune and train them properly. (Like making so that manual fixes improve the algorithm)