I'm working on a project that has two languages so far, German and English. Most of our team (devs, designers, QA) know both well. We use Gettext, all translations are applied directly by devs in the .po files in our repo. The designers come up with the texts, either on their own or with the help of dedicated copywriters, and tell the devs which text to insert where, as part of a ticket description.
Now we need to add more languages, languages that our team doesn't know, and we need a process improvement.
The biggest problem with our current approach is that only devs can get a good sense of context when adding a translated text because it requires searching for gettext("Hello there...") in our templates, so it requires access to our code base and some programming knowledge.
Another problem is the fact that devs need to be involved for any minor wording change.
Recently we also realized that seeing all translations in a monospace font leads to confusion. For example, a dev browsing .po files in their IDE with a monospace font won't notice the difference between a hyphen-minus, a hyphen, a minus, an en-dash, and an em-dash. Ideally, devs wouldn't even need to care about that.
In my last job we used crowdin.com/ to manage the translations. It proved to be very effective tool, although it was not free. Let me address your main questions/painpoints.
What does the process look like?
The process can be completely automated. Devs add new strings in the App. The CI detects it and will extract source English language template strings and upload them directly to translation tool.
Which tools do you use to allow translators work on the translations?
Gettext in APP (backend), i18next.com/ on frontend and crowdin.com/ for doing actual translations.
Do you even have dedicated translators?
it's possible to hire translator directly via crowdin platform. The pricing was reasonable.
How do you provide context for the translators so that they know what exactly they're translating?
Crowdin has a context feature, that allows you to associate app screenshots with extracted strings. And if you're using gettext, you can provide context as part of source string definition.
Working in pairs with someone who knows the app, writing descriptions, attaching screenshots? Or are you able to do in-app translations with some JS magic?
Giving access for translators to your staging env is necessary. They need to proofread what they created by browsing the application. Some guide must be created to guide them step by step through the App.
Do you use Gettext or something else? Do you use more than one Gettext domain?
Gettext is fine. With domains + context it gives you everything you should need. On frontend the tooling is not that mature, but still react-intl + i18next are fair tools for the job.
How many languages do you have to handle?
6 languages in 2 months
What is the biggest pain point of your process?
Not having as mature tools for frontend as they exists for backend. Extracting in frontend was not so precise and required verification.
How do you handle quality assurance of the translations?
Translators are asked to proofread what they translated on staging env. Even better is hire another native lang speaker or different translator to proofread the work of the original translator.
Sometimes it help to maintain just english context tokens as original "en" source language and have actual english "en-US" as separate translation. That way, devs don't need to touch the App that much to change source strings and marketing or product teams can change the "en-US" directly via crowdin platform. This solves the problem of devs spending a lot of time on source language tokens.
I'm working on a project that has two languages so far, German and English. Most of our team (devs, designers, QA) know both well. We use Gettext, all translations are applied directly by devs in the
.pofiles in our repo. The designers come up with the texts, either on their own or with the help of dedicated copywriters, and tell the devs which text to insert where, as part of a ticket description.Now we need to add more languages, languages that our team doesn't know, and we need a process improvement.
The biggest problem with our current approach is that only devs can get a good sense of context when adding a translated text because it requires searching for
gettext("Hello there...")in our templates, so it requires access to our code base and some programming knowledge.Another problem is the fact that devs need to be involved for any minor wording change.
Recently we also realized that seeing all translations in a monospace font leads to confusion. For example, a dev browsing
.pofiles in their IDE with a monospace font won't notice the difference between a hyphen-minus, a hyphen, a minus, an en-dash, and an em-dash. Ideally, devs wouldn't even need to care about that.In my last job we used crowdin.com/ to manage the translations. It proved to be very effective tool, although it was not free. Let me address your main questions/painpoints.
What does the process look like?The process can be completely automated. Devs add new strings in the App. The CI detects it and will extract source English language template strings and upload them directly to translation tool.
Which tools do you use to allow translators work on the translations?Gettext in APP (backend), i18next.com/ on frontend and crowdin.com/ for doing actual translations.
Do you even have dedicated translators?it's possible to hire translator directly via crowdin platform. The pricing was reasonable.
How do you provide context for the translators so that they know what exactly they're translating?Crowdin has a context feature, that allows you to associate app screenshots with extracted strings. And if you're using gettext, you can provide context as part of source string definition.
Working in pairs with someone who knows the app, writing descriptions, attaching screenshots? Or are you able to do in-app translations with some JS magic?Giving access for translators to your staging env is necessary. They need to proofread what they created by browsing the application. Some guide must be created to guide them step by step through the App.
Do you use Gettext or something else? Do you use more than one Gettext domain?Gettext is fine. With domains + context it gives you everything you should need. On frontend the tooling is not that mature, but still react-intl + i18next are fair tools for the job.
How many languages do you have to handle?6 languages in 2 months
What is the biggest pain point of your process?Not having as mature tools for frontend as they exists for backend. Extracting in frontend was not so precise and required verification.
How do you handle quality assurance of the translations?Translators are asked to proofread what they translated on staging env. Even better is hire another native lang speaker or different translator to proofread the work of the original translator.
Sometimes it help to maintain just english context tokens as original "en" source language and have actual english "en-US" as separate translation. That way, devs don't need to touch the App that much to change source strings and marketing or product teams can change the "en-US" directly via crowdin platform. This solves the problem of devs spending a lot of time on source language tokens.
That was extremely helpful, thank you! I have been evaluating Crowdin the past week and it seems like a good fit for my project too.
Glad I could help. If you’ll have more specific questions about mentioned technologies just let me know and I’ll try to help.