← Retour aux issues

i18n and t9n : internationalised and english / other languages / version

publié le , mis à jour
Avatar github de laemlaem

There won't be a i18n version of Cartes in the medium term. There are a number of reasons.

First, the complexity it inflicts on the project, while dev resources are super-constrained. There are many talented devs in France and other French-speaking countries, that we for now haven't been able to mobilise.

i18n without a team (that can be benevolent) doesn't work : at work on a paid state project, we i18ned a project for nothing : without local communication in each country, it didn't take off. Three months of translation, a code base 2x as complex (yes, having to change a UI that is now in a language you don't master / with translation keys everywhere / with CI that breaks when you forgot to translate, with translation taking 50 % of PRs), for... still 99% French-speaking users.

I also like the idea of devoting 100% of the initial dev time to the French version in the early phases of the project. It's a rare thing. The people around me are 99% French-speaking, and they motivate me. In France, apart from well funded projects, translations in French are often bad. Look at this platform where we're developing : the github team is for political reasons not introducing translation, despite their wealth. This needs to be counterbalanced.

Also keep in mind that It's possible that in 6 months' time, the use of Cartes won't be wide, that the assumptions about the ingredients for success weren't the right ones. I prefer to test a roll-out in France and expand only if there is initial success. As I write these lines, 8 months after the start, we have no more than 20 000 users per month. It's not enough to think international :rocket:.

Of course, if someone is willing to devote 3 months at 2 days a week, plus a maintenance effort over time of multiple days per month (a rough estimate), we'll be happy to discuss translation.

Of course, something that doesn't work in France, for various reasons, could work abroad if e.g. backed by an organisation that has the will, the money and / or the firepower to promote a translated version of Cartes.

We'll then have to discuss with limited time about the state of the art frameworks for translation, that should not dramatically impair dev time. We don't want yet to slow down.

Last but not least, on top of t9n, i18n is hard. In France, we haven't yet been able to correctly display the local language translation of places, only the breton language is. We haven't yet been able to integrate the transit data of all of the french hexagone. Etc.

For example, the transitous project, quite similar to laem/gtfs+laem/motis, went all-in on international coverage, instead of starting small and being sure that transit works in all of e.g. France before trying germany. They've got world coverage, but last time I tried my regional capital city of Rennes didn't work. Well maybe they just undesrestimated France's digial illiteracy ^^ : lots of GTFS data in France have to be retreated to work. Could be way simpler in Switzerland or Germany (and probably way more complex in other countries).

  1. Avatar github de laemlaem

    Damn, we should really expose most issues on the website. It's unfair that github.com gets this content's search karma, and gets drown in billions of similar content :/

  2. Avatar github de gedankenstueckegedankenstuecke

    Thanks for opening the issue, totally understand not wanting to dedicate resources to it, especially when the effort to get it into a state that's ready for taking in translations would be that big. I hope one day that'll change! ❤️

  3. Avatar github de laemlaem

    Very interesting project https://github.com/tolgee/tolgee-platform In situ translation is a very promising feature + a JS api.

  4. Avatar github de laemlaem

    With @colinmaudry we've tested Tolgee quickly. It's interesting but we have to look the possibility of using Tolgee without switching to an HTML that only contains ids instead of real human text. I want the HTML code to still work without the t9n tool.

    E.g. this code block obfuscate the real intent of this component : we're missing the essentiel part in the HTML, the innerText of the h1 tag.

    <header><h1 key="osmViewer.title"/></header>

    The React introductory video shows what a component looks like : https://www.youtube.com/watch?v=-oBuDsKoJWU image

  5. Avatar github de ColinMaudryColinMaudry

    How it works with inline tags in React (from Tolgee docs):

    const Component = () => {
  return (
    <div>
      <T
        keyName="translation_key"
        params={{ i: <i /> }}
        defaultValue="This is <i>formatted</i>"
      />
    </div>
  );
};
  6. Avatar github de ColinMaudryColinMaudry

    For reference, how Transifex does it in next.js. The setup looks tedious. There is also the possibly to hook Transifex with i18next extension.

  7. Avatar github de laemlaem

    Lingui seems interesting, using either explicit or generated ids https://lingui.dev/guides/explicit-vs-generated-ids

✏️ Participer à la discussion