Dev guideslines for making translation easier

dev translations
1

I’m aware of topics and guidelines for translators, but are there guidelines anywhere for devs so that they can make translation easier?

If not, I have a few ideas :slight_smile:

  • Avoid ‘walls of text’. tos_topic.body is totally unwieldy, for example. And that’s if you just have to translate it the once. But every time there is a modification, you have to scroll up/down to find the differences.
  • Try to avoid ambiguity (i.e. does “User Modified” mean “modified by the user” or “the user has been modified”?). You don’t necessarily need to make the distinction in the text, using the key to disambiguate is a good idea too.
  • Don’t hard code a language-specific url inside a no-translate tag (at this time site_settings.discourse_chronos_default_timezones has a link to an EN WikiPedia page embedded in a no-translate tag)
  • Don’t forget that you should use the alternate translations for texts involving counts of 1 and n.

(Feel free to add other ideas)

5 Likes
2

As a translator I feel your pain. Fortunately there are only a handful of very long texts. There is already a topic where we discussed possible solutions: https://meta.discourse.org/t/maintaining-huge-translated-strings-in-transifex/27413

As an alternative, it’s also possible to add comments within the YAML files. They show up in Transifex.

https://github.com/discourse/discourse/blob/master/config/locales/client.en.yml#L19-L24

4 Likes
3

Be careful about splitting nouns and their adjectives into separate strings. It seems practical in English:

{count} tags
{count} topics
{count} users
deleted
updated
selected

But this creates problems in languages where you have to accord the adjective with the count (and gender) of the noun.

(An equivalent example in English would be if you were to split the {count} from the tags - you wouldn’t know whether to write tags or tag.)

4

Try to avoid creating duplicate texts. I know it’s a bother when you’re in the zone to have to break out and go and see if it already exists, but your effort has leverage because it reduces the work required for the N language translators down the line.

Alternatively, consolidation could be considered a separate dev task, but the earlier it is done the better, because once it gets onto Transifex, the translators will be on it.

5

That’s actually bad advice in most cases. We try to avoid reusing texts whenever something could have a different meaning based on context or simply might need a different translation because there is less room for text in the UI.

We did enable translation autofill on Transifex a couple of months ago which will automatically fill new and changed texts with existing translation for the same phrase and makes this a lot easier for translators.

1 Like
6

OK. Point taken. It’s still a problem when there are minor variations on a theme.