Worldcubeassociation.org: Document the process for adding a translation of the website

[viroulep]

In the end we'll need some documentation to make the job of the translators easy.

This include:

• write something somewhere (wiki ?) describing the process
• preparing a list of files to translate
• comment these files to give some context for the use of the translation

[larspetrus]

I worry about development speed. Currently we can write and deploy new UI code in hours.

If we have to wait for proper translations to 5 languages, I seems it could easily take weeks.

[jfly]

Oh, I certainly don't imagine us blocking on translations. As with the WCA Regulations, translating is going to be a best effort thing that members of the various communities are going to have to do when they feel it needs to be done. We should just do everything we can to make their jobs as easy as possible.

[viroulep]

Idea for later: have the translators keep the commit hash of the English version the translation is based on within the (foreign) locale file, so that it's easy to show a diff of what's changed and need to be translated.

The way I saw next UI developments is that software team would used keys in the English dictionary instead of plain strings, and would not worry at all about translation being up to date.

[jfly]

Hmm... do we really need a commit hash to achieve this? I think we should just be using this "completeness test": https://github.com/svenfuchs/rails-i18n#test-your-locale-file

[larspetrus]

So when we add new text to a page, that part will be in English on an otherwise French language page, until someone voluntarily submits a translation?

[jfly]

That's what I was imagining, yes. We're not going for perfect here, just something that will let the people who ask about #289 actually be able to contribute (I'm pretty sure they're all willing to translate stuff).

[larspetrus]

Oh, wow!!

That makes me much less worried about dev speed, and much more worried about translation quality :)

I guess it works as long as it's clear.

It could be worth it to put a disclaimer on the translated pages explaining that it might lag behind English, and talk to this person contribute.

[viroulep]

One step to make the translator job easier would be to have a clearly structured layout for the yml file.

Right now I've chosen simplicity for the developer instead of simplicity for the translator (ie: I wrote the yml depending on the rails context where the key is used).

One way to layout the yml could be:

en:
  controllerX:
    errors:
      wrong: "Something wrong"
    flash:
      login: "Please login"
    form:
      somefield: "Some additional hint"
    messages:
      someinfo: "Some non-flash info displayed on top"
    navigation:
      home: "Home"
    text:
      page_description: "Some long text that may have %{variable} and that does not fit elsewhere"
  # etc for other controllers
  activerecord:
  # The activerecord things
  simple_form:
  # The simple_form things

We should probably keep the activerecord and simple_form, it's very convenient and pretty straightforward to understand.

[viroulep]

Done in this wiki page.