Finished the localization for Simplified Chinese, wish to join the contributor party

[nekomeowww]

Hello @carloscuesta 😎!

Several days ago I forked your repo here and created the new one as the source repo: https://github.com/nekomeowww/gitmoji-zhcn
And I finished the Simplified Chinese localization with the new site deployed on this repo: https://github.com/nekomeowww/gitmoji

Which is powered by GitHub Pages to the brand new site for Chinese: https://neko.ayaka.moe/gitmoji/

I wish to know a way to join one of the collaborators here. Since I have my contribution to my repo.
Or we can work out a way to make more internationalization possible throughout the browser detection or user selection.

[johannchopin]

Hey @nekomeowww 👋 Open an issue is the best way to contact a contributor 😉 Localisation is a nice topic for gitmoji (many peoples ask for it) but it make then the project harder to maintain (if you change a sentence, you will need to change all the sentence in each 'supported' language). But IMHO it's possible to handle it in a project with +8k⭐.

I already implemented localisation in multiple projects but I will first wait for the opinion of @carloscuesta.

[nekomeowww]

Sure happy to be heard that.
I have multiple projects that implemented the localization too, but however this is obviously his choice to be made.
Thank you for replying to me. 😉

[vhoyer]

having localization would be awesome, although it would really make it difficult, haha 🤔

I will give an idea here, but I think it's not a great idea, but we can maybe work from there (considering we will indeed follow up on internationalizing the website).

We could add, in each language, the version that language is current representing, so the english (global) mainteined by all of us will be the, like X.Y.0, and the chinese maybe will be at X-1.0.0, and maybe a portuguese would be at X.Y-2.0. along side with a message saying "oh, the messages in this language are outdated, for an up-to-date version, switch to english language or open a PR in your native language".

One problem I can expect happening is having several threads that are non-english, which would be kinda hard to maintain, but, as a possible solution I just thought of, we could have issues dedicated to a language translation like 翻译 [Chinese translations] and this issue would be forever green so that people that want to collaborate only with translations get a place to discuss with everyone interested on the language and we maintain the repo mostly on english with only those issues with other languages.

---

Well, it will be difficult, so I donno if it would be feasible, anyway, let's wait more opinions on this :D

[nekomeowww]

It's wonderful to have your words here. For me, I have worked around for many project's localization functionalitie, cause Chinese is not the common language for people to use the service online, my projects, and the joined ones always have the ability to have a different language switcher.

As for the problem you have said here.

and the Chinese maybe will be at X-1.0.0, and maybe a Portuguese would be at X.Y-2.0

You can have the default English native words in your document, import the target language if accessible, this may be one of the workarounds for that.

Anyways, since I have deployed the Simplified Chinese version online, my friends and many users are using it for now.
We would wait for more opinions.

[johannchopin]

I have also an idea of how to maintain this stuffs.

Lets say we will have a folder localisations that contain all the translations:

├── localisations
│   ├── en.json
│   └── zh.json

Each of theses translations files are a json that can have this structure:

{
  "version": string,
  "translations": {
    "key": "sentence",
    ... 
  }
}

We will say that the en translation file should be the reference for all the other files (so all the other files should have the same version than en).

Then we can add a Localisation section in the README that contain a list of all languages with their version. So it can be a list of badges:

• If the language has a lower version than en, then we display a critical badge:
  

• If it has the latest version, then the badge should be success:
  

With theses indicator in the README it will definitively motivate people to update the translations in their language 👍

To finish, it can be easy to create an updateLocalisationsStatus.js node script that parse all the localisations files, check the version and update the badges in the README. The badge can be easily created using this url template https://img.shields.io/static/v1?label=<LANGUAGE>&message=<VERSION>&color=<COLOR> where <COLOR> is success or critical.

So if someone update a translations, it has to run this script locally and push the generated README (and we will need to take care that it has been done in the CR).

What your opinion on this approach?

[nekomeowww]

A great idea to have.

We will say that the en translation file should be the reference for all the other files (so all the other files should have the same version than en).

This is definitely true for the localization process since this project is as user sponsor and contributable project, there might be many changes that needs to be done.
And we can also link our translation files to the collaborating translation hosting web services to have people to localize them if any of them would have no idea of how to code.

[carloscuesta]

The problems I see with the i18n of the site are:

• Maintainance of the languages
• Contributions should update every language and for languages like Chinese I think this will be really difficult to maintain. Because we will need a native speaker who is able to understand English properly and the language of the translation per each PR to review the contents 👎🏼 .

That's why I not decided yet to translate the whole project. I understand that some users could feel confused as the project is not translated into their own language.

The project now has an "easy to" contribute status. Adding i18n will add a lot of complexity to that process. Especially if anyone who wants to add a gitmoji should translate the description title and name to every language that is on the project. Considering that is an OSS project, no one should be tied to it. We invest our free time on doing this, so you can't expect to make someone work on this to help with the translation issues.

[johannchopin]

@carloscuesta I guess that if a user add or modify something, he should first only do it in english (and makes some translations if he want). With the process explained in #560 (comment), the README will show some fancy critical badge which could easily catch developer intention:

In the OSS world there are a lot of developer that invest their time by fixing typo or doing 'maintenance' stuffs. So I guess with gitmoji we will find some guys with interest in translating sentences ;)

[carloscuesta]

@johannchopin For me it's not an option for a Pull Request to include the english language and leave the other supported languages empty. If you offer i18n on a project do it right, or don't offer a solution.

Because the UX of the other languages would be really poor, because you'll find that there are a lot of translations that are missing and you'll find some Gitmoji cards empty on languages that are not english.

I think we should find something that does not depends on contributions and we need to find a way to automate this. Because depending on contributors and humans it's not a scalable solution.

Also the approach you provided at #560 (comment) it's not bad but I don't quite like the versioning concept if it's not tied to a "tag version system". This is convention IMHO would be hard to enforce on PRs since it'll depend again on reviewer eyes and trust me, you want to automate everything on the long term. Also filling up the README with a ton of badges of languages (that we will have to update manually) adds a lot of unnecessary bloat to the project readme.

[KaKi87]

There is no way to automate translations unless you don't care about quality.

[vhoyer]

well, all this is true. Maybe we could make it easier for people like @nekomeowww to create forks with translations and or you could work on an automated issue that would notify the interested people that the gitmoji.json changed texts.

Like, every time there is a change in a description we could add a message in this issue to let people that have translation forks to know easily that there was a change?

Just an ideia, I don't even know if this is a real problem 😓

[KaKi87]

Yes. Also if you really want to absolutely enforce up to date translations, you can make the brutal choice of automatically hiding languages that are incomplete or not updated. But at least localization will be implemented.

[KaKi87]

I'm interested in making french translation. What's the status for the technical implementation of i18n on Gitmoji ?

[carloscuesta]

The technical implementation is not the problem. It's really easy to add i18n support to a Next.js project. The problem as I said before with this is the maintainability issues we are going to have with the translations.

I don't see a clear path right now for making this automatically. Until we didn't figure out a solution for this I won't move towards introducing i18n on the project.

I think we should find something that does not depends on contributions and we need to find a way to automate this. Because depending on contributors and humans it's not a scalable solution.

[KaKi87]

Well, I offered you the solution

if you really want to absolutely enforce up to date translations, you can make the brutal choice of automatically hiding languages that are incomplete or not updated. But at least localization will be implemented.

Also

There is no way to automate translations unless you don't care about quality.

[carloscuesta]

This is not a good solution. Because the translations will not be visible to the user so you're making a lot of work to not provide any real value.

if you really want to absolutely enforce up to date translations, you can make the brutal choice of automatically hiding languages that are incomplete or not updated. But at least localization will be implemented.