Translation Update

Hi everyone.

I wanted to give you a little update on thoughts and decisions about translation!


Firstly, thanks if you gave feedback on here or Discord. It was very interesting and useful to read everything.

My overarching conclusions from reading hundreds of messages are:

  1. If you’re in the US/EU, you’re probably going to use English in the workplace. Outside of those places, that’s less the case.
  2. If you don’t have English skills, then you probably need English skills to work for a US/EU company, but not for the majority of the world.
  3. So if you’re in US/EU, translation matters less. Outside it matters lots.
  4. Nearly everyone commenting on this learnt English to a passable level before the age of 18. The vast majority of the world don’t fit this profile.

So I think translating Exercism is likely to be incredibly valuable for people who are not in the US/EU, but less valuable for those who are.


Based on this, we’re going to continue forward with the initiative!

Here’s progress/decisions:

  1. We’ve now converted the whole website from text to i18n keys (enjoy the PR crashing your computer), and put together a first set of translations in Hungarian (Aron’s native language - so he’s been testing it as he’s gone). That’s deploying as I type this.
  2. I’ve decided not to use GitHub for translations. After considering your responses, I think it’ll add hassle/effort for maintainers, bloat the repos, and make it hard for translators to actually see what needs doing. Instead, we’re rolling out our own simple translation UI, where all text is translated via LLMs, and translators can approve/edit those. We’ll have that finished in the next couple of days.
  3. There’s then some more advanced functionality I want to add, like only translating bits that are changed in English to reduce translation burden and maintain human translations rather than re-machine-translating everything each time. So that’ll be something I’m working on this week.
  4. I’ve also been working on things like the showing a user/visitor the right language, and how to best do this with SEO, caching and the like. That’ll hopefully be finished today.
  5. In parallel, I’ll be emailing our users to ask if people want to help, and giving people a sign-up page to register interest. Based on that, we’ll determine which languages to start with.

My aim is to have all this ready to start translating in the first week of September.

The main thing is that basically this will be entirely parallel to the normal maintenance of Exercism now, so not something that maintainers need to think about at all, unless they want to help translating. Which I think is good/important!


Thanks for reading. I’ll keep you updated! :blue_heart:

14 Likes

Hello,

Thanks for the update! This looks like a promising work to give access to the most persons.

  1. We’ve now converted the whole website from text to i18n keys (enjoy the PR crashing your computer), and put together a first set of translations in Hungarian (Aron’s native language - so he’s been testing it as he’s gone). That’s deploying as I type this.

In fact, that is a HUUGE pull request. I skimmed a bit through it, and I would like to make a small suggestion: prefer using full translation keys instead of composing them from string parts:

-const prefix = 'my_prefix'
-t(prefix + '.suffix')
+t('my_prefix.suffix')

I found out that this helps find dead translations as well as list all the required keys, furthermore this simplify linking the translation to its source during devlopment.

  1. I’ve decided not to use GitHub for translations.

I think that is a great choice, as this translation noise can be tedious to review if you do not know the language. That said, did you consider existing platforms (some of them could be self-hosted) like:

In fact, those platforms offeo tools to help with translation. Some of them are:

  1. Suggest strings with the same translations
  2. Review translations and translation history
  3. Propose a glossary to ensure technical words are translated the sames
  4. Derive a locale from another (for instance, en_US, en_CA and en_UK share a lot of similarities)
  5. Have automated translation tools that just need a review
2 Likes

Thanks!

I think the vast majority much all do do that. Is there somewhere you’re seeing this a lot in the P

I did, yes. The main reasons not to use them were all of the custom use-cases we have (e.g. awarding reputation for helping, maintaining human-edited blocks of text when exercises change and only converting bits in a diff, translating problem-spec files then applying those to exercises, etc).

We’ll be adding glossaries and language-specific context files for translations too.

When I looked at the features they provide, I felt that 90% of it could be replicated in a week or two of coding, and that that would probably be more efficient than trying to understand how to shoehorn our use-cases into their flows etc. It only took 3 days to build a fully-working backend for this, with LLM translations and review flows, and I think it’ll only take Aron a week to do all the front-end for it, so I think it’s probably the right decision.

But I really appreciate you pointing them to me :slight_smile:

2 Likes

There is at least one place in the beginning of the diff app/helpers/user_tracks_helper.rb

I did, yes. The main reasons not to use them were all of the custom use-cases we have […]

Thanks for your explanations on this subject. In fact this seems like a genuine choice given all the customization that is expected.

1 Like