Translations in 2018



  • We are looking to add translation/i18n support to our react project. There are plenty of options to handle this on the programming end. I am, however, less clear on how to handle this from the translators' end.

    Do they have some industry-wide program they use? In which format should I supply translation files? Or should I provide a web interface for them to use? And which one?


  • 🚽 Regular

    @cartman82 said in Translations in 2018:

    We are looking to add translation/i18n support to our react project. There are plenty of options to handle this on the programming end. I am, however, less clear on how to handle this from the translators' end.

    Do they have some industry-wide program they use? In which format should I supply translation files? Or should I provide a web interface for them to use? And which one?

    FWIW when I had translations made I supplied the source in a Word document.

    The translator was really interested in getting as much context as possible for each string though:

    "Disable heat-exchanger thermal limit"
    A setting that disables the maximum operating-temperature limitation on a mechanical device that transfers heat between two systems.


  • Notification Spam Recipient

    @cursorkeys said in Translations in 2018:

    @cartman82 said in Translations in 2018:

    We are looking to add translation/i18n support to our react project. There are plenty of options to handle this on the programming end. I am, however, less clear on how to handle this from the translators' end.

    Do they have some industry-wide program they use? In which format should I supply translation files? Or should I provide a web interface for them to use? And which one?

    FWIW when I had translations made I supplied the source in a Word document.

    The translator was really interested in getting as much context as possible for each string though:

    "Disable heat-exchanger thermal limit"
    A setting that disables the maximum operating-temperature limitation on a mechanical device that transfers heat between two systems.

    This! Is very important for accurate translations.

    My vague recollection was there was no industry standard. Every firm had their own method of doing shit which was a ball ache and a half when it came to exporting the strings they needed to translate. Excel oddly enough was the easiest to use.


  • Fake News

    We used to do this in CSV files which got swapped around (we had a few rounds of trouble where some strings got translated by different translators and they forgot to merge the other's text, so suddenly a fixed translation in one part got broken while another got fixed. That's why we were looking for an alternative).
    We converted those CSVs into JSON files which our Knockout FE reads. Keys now come in "groups" based on which functionality they're used for, and within each group we have a JSON file "en.json", "de.json", etc. containing a bunch of keys.

    Then later we used to translate all those JSON files directly with a custom website and had a development tool which would connect to the website to grab all groups and keys, then spit out the JSON files so a developer can commit them to the product's git repo.

    Since the custom tool was aging our CTO decided to replace it with Weblate. This software will now modify a dedicated "localisations" git repo directly to store the JSON files, and our software's git repo simply references the localisations repo as a git sub-module.

    Somebody still needs to remember to update the sub-module's metadata (git submodules lock onto a given commit id and will not automatically follow a branch), but at least it now uses standard git commands rather than a custom tool which generates the JSON files.



  • @cursorkeys said in Translations in 2018:

    The translator was really interested in getting as much context as possible for each string though

    ^ This. As someone who has translated computer programs before, I cannot stress the importance of this enough. That's why gettext can extract comments from the source and put them in the translation template.

    w.r.t tools I don't want to give any recommendation. Gettext sucks the least IMO, but I'm not sure every translator will like it. I think there are web applications that provide a nice interface for gettext, though, so if you find a good one, then gettext may be the best choice.



  • Thanks! These are all very useful. My colleague is looking into this, but he's kind of stuck in the mud. He needs some guidance.

    The last time I did translations, I think I did it through yaml files that I handed off to translators. It was all fine and good while I was working with a in-house girl who was fairly competent. The moment I had to pass this around to random people on the internet, I ended up having to rewrite all files manually.

    (try explaining to people they need a text editor and that word won't cut it).

    So GUI is a must.



  • A quick Google search brought up https://www.transifex.com/. The feature list (glossary, translation memory, ...) looks nice. Might be worth looking at it you're not completely opposed to spending money on this.



  • @dfdub said in Translations in 2018:

    A quick Google search brought up https://www.transifex.com/. The feature list (glossary, translation memory, ...) looks nice. Might be worth looking at it you're not completely opposed to spending money on this.

    Not opposed to spending money, but probably opposed to cloud. Boss insists everything is to be self-hosted, so...


  • area_can

    @cartman82 said in Translations in 2018:

    In which format should I supply translation files?

    My last place used Xliff. Take a look: https://www.transifex.com/blog/2016/common-localization-file-formats/



  • @cartman82 Another gettext GUI: https://poedit.net/



  • @dfdub said in Translations in 2018:

    @cartman82 Another gettext GUI: https://poedit.net/

    We were looking into po.

    The problem is, it doesn't seem to be too popular in the react/typescript land. So we might have to cobble together some monster translation chain where files are getting rewritten between different formats multiple times.

    Still might take it.



  • @bb36e said in Translations in 2018:

    @cartman82 said in Translations in 2018:

    In which format should I supply translation files?

    My last place used Xliff. Take a look: https://www.transifex.com/blog/2016/common-localization-file-formats/

    I vaguely remember using that as well. I think I used Virtaal as a GUI back then and remember it being a buggy piece of crap. That was more than 5 years ago at my old job, though, so maybe the GUI is better now.



  • @bb36e said in Translations in 2018:

    My last place used Xliff. Take a look: https://www.transifex.com/blog/2016/common-localization-file-formats/

    Doesn't seem too popular on the frontend, outside the angular land.

    It seems react is more into yahoo's intl system



  • The colleague who's working on this, The Bore, found some solution that involves our apps going to some 3rd party API and downloading translations from there during app bootup (all translations being hosted and edited on the SaaS provider).

    He looooves "simple" solutions like that, where he find some super-elaborate "key-in-hands" framework and just plugs it in. Simple for him right now, of course, not simple for end users or security or long-term health of the project. I'm getting pissed off just thinking about it.

    Hopefully, the super paranoid boss will put a stop to this nonsense.

    For fucks sake, STOP LOOKING FOR EXPRESS-REACT-INTEGRATED-INTL-MIDDLEWARE-PROVIDER-KEY-IN-HAND-25MB-BUNDLE-SHITPILE! All you need is ONE fucking function and a file with translations. THAT'S IT. Gah.


  • Considered Harmful

    Really depends on your platform. For example, C# has its own localization system.



  • @cartman82 That sounds pretty similar to a CDN for letters on a coloured background.



  • @cartman82 Last time I had to deal with it, we just used an excel sheet with a column for the english term, a column for the context, and a column for each language. Simple, but worked.

    Probably space for a business here, I bet.



  • @blakeyrat said in Translations in 2018:

    @cartman82 Last time I had to deal with it, we just used an excel sheet with a column for the english term, a column for the context, and a column for each language. Simple, but worked.

    Probably space for a business here, I bet.

    There already is, it's the thing Bore luvs.



  • @cartman82 Well if they let you download the translation data in various formats, that might be close to what I'm thinking. If you have to make an API call for every visitor to the website, that's pretty crappy.


Log in to reply