← Retour aux issues

i18n

publié le , mis à jour
Avatar github de laemlaem

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

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

  8. Avatar github de martin-mitomartin-mito

    I've read the blog article "Cartes, a free european alternative to Google Maps" and I have to be honest, internationalization is also not needed imho. There are other initiatives for a global GMaps Online alternatives like osmapp.org or OSM NG.

    FOSS projects unfortunately often suffer from insufficient coordination. If Cartes would go international it would compete with other FOSS initiatives which would be a waste of resources.

  9. Avatar github de laemlaem

    There are other initiatives for a global GMaps Online alternatives like osmapp.org or OSM NG.

    OSM NG is not an end-user interface project, but a rewrite of OSM-the-database and collaboration infrastructure. We'll use it if it makes it to production.

    Osmapp is a direct competitor, but we're using the same technologies, and sharing code is easy and already done multiple times. But its scope is not as large as we ambition here, for instance public transit.

    We will happily let other projects join our initiative, or vice-versa, or more pragmatically share bricks of code, once we've gone international. Osmapp, Organic, NG are all aware of our initiative but legitimately don't bother spending time on the matter as long as we're staying French-only.

    FOSS projects unfortunately often suffer from insufficient coordination. If Cartes would go international it would compete with other FOSS initiatives which would be a waste of resources.

    In the long term, we believe the error would be the other way : not letting German, Spanish people us what we're working instead of letting them recode everything.

  10. Avatar github de laemlaem

    We've published a new article in English too https://cartes.app/blog/digital-relocation. Our blog now supports writing fr and en.

  11. Avatar github de laemlaem

    Things to do to have an internationalised version of cartes.app.

    Needed

    • translate the interface in english as per the principles and using the tools listed above

    I'd say ⌚️5 days of work for a first version, and ⌚️5 days more to communicate to abroad communities and get the first native translation corrections and make the contribution process fluid. It would of course use a LLM to produce the first exhaustive translation to be iterated on.

    • make sure the international tiles that we use (built by Panoramax) out of the scope of France render correctly despite our style customisation for our tile customisations. E.g. "maxspeed->road color" can be displayed on our custom tiles.

    ⌚️1 day

    • handle proper translation of Wikipedia extracts, remove French specific things like "gare SNCF"

    ⌚️0.5 day

    Good to have

    • use Transitous as a Motis server backup for the rest of the world. Our server covers France with some things on top of Motis (e.g. maps of transit lines) but a degraded functionnality would still be largely worthwile. We'd have to switch ours to Motis v2 as a prerequirement. I believe the Transitous community would be very happy to see this integrated.

    ⌚️1 day (most work going into v2 transition)

    • compute tiles of Europe and then the world in our enhanced OMT tile format. It's important to give a harmonized and enhance map experience worlwide

    This is quite a challenge : computing our France/part of Europe tiles is already high on our server's resources. We need more RAM to do this with Tilemaker. Ideally, we'd spawn a dedicated and strong instance on Scaleway's network just for this, download it and shut the instance.

    ⌚️3 days for Europe, should scale to the world quite easily then.

    • translate the interface to the other european languages

    Once the framework is in place, LLM translations should be able to provide usable translations to be augmented by native corrections in the medium run.

    ⌚️3 days (work + some communication).

    Total : 18.5 days.

✏️ Participer à la discussion