[yarcob]

Or maybe the translator should get annotated screenshots of the app. Laid out in a story board.

If you just hand someone a list of strings to translate, there's no way you'll get sensible results.

Also, you should test you translations. Some of the translations that I've seen (even from reputable companies) are so bad that it's pretty obvious no native speaker has ever looked them over.

[travisjungroth]

The tension is that people want to reuse translations. So maybe you have the story board for the first version. Then, someone makes a new button. In Django, they'd put _("Open ticket") as the text, see there's already a translation, and think they're good to go. Sure, having every page looked at by a translator for every language every time you make a change would be ideal, but also a bit costly and slow. I think there are better options in the middle.

[yarcob]

I don't think there are any "middle options" that result in a good product. You want a localized app, but you don't want to put the work in.

If you add some new text somewhere in the UI, you need to start the app and make sure it looks right. If you only do that for one language, and don't check other languages, then there's going to be one language that's broken.

So your app is going to look broken in one language. And you probably will never find out, because the people who run into the bug don't speak your language.

[travisjungroth]

> You want X, but you don't want to put the work in.

Yes! That is exactly what people want.

[david_allison]

> Also, you should test you translations. Some of the translations that I've seen (even from reputable companies) are so bad that it's pretty obvious no native speaker has ever looked them over.

Testing is a must. Before I fixed + linted it, we often had community-provided translations which would cause the app to crash due to missing/additional format strings.