Git-point: Localization

[RolfKoenders]

Show the app in the language of the user's phone. Later on this could be changed in an options menu?

[TautFlorian]

Dont think that's very necessary, most repos are in English anyway also the issues and PRs. So only you're ui would be in your language.

Just my opinion think in English is better somehow...

[SammyIsra]

I think the recommendation was not to change the language of the repositories and users (I personally don't think that would be possible or a good idea) but to change the language of the app itself to the the language of the phone. Stuff like Log In, Sign Out, and so on.

[RolfKoenders]

@SammyIsra Exactly! the app itself. Like buttons/titles etc. We could use the default language of the phone for this and/or let the user set hes preferred language.

[housseindjirdeh]

Agreed this would definitely be really nice to have. So there's two things I think we should finalize before we start this:

1. Which languages do we want supported?
2. Do we have any volunteers who would be willing to write copy for those languages?

Just for some info, here are the regions of most downloads.

Of course that does not have to be in the order of languages we begin to support, I'm all for including any language with which we having a willing contributor :)

To start things off, I can include react-native-i18n and layer out all the current english copy into a translations file with which we can close this issue. We can then decide to add specific languages and open an issue for each of them. How does that sound?

Always open to suggestions of any kind 💬

[lex111]

@housseindjirdeh sounds good! I'll do Russian translation :smiley:

[RolfKoenders]

I can do the dutch (Netherlands) translation.

[housseindjirdeh]

Love you guys <3

Will have localization set up today or tomorrow hopefully 🙌

[Antoine38660]

I can do the French translation 🇫🇷 😄

[SammyIsra]

I can do Spanish!

On Jul 27, 2017 6:12 PM, "Antoine" [e-mail] wrote:

I can do the French translation 🇫🇷 😄

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitpoint/git-point/issues/117#issuecomment-318501356,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIjAtBdS0OeGDv2229gDxQ1SXURRVllFks5sSQtggaJpZM4Ob-Ae
.

[housseindjirdeh]

🎉 🎉 You guys are awesome, I'm going to have it setup tonight if I have time. I want it out before our next update so we don't need to add native code when we decide to add the newer languages thanks to CodePush :)

[housseindjirdeh]

With localization functionality in, will close this. I'll open separate issues for each translation :)

[machour]

@housseindjirdeh while doing the french translation [1], I noticed a few remaining hardcoded english strings.

In my usual translation process, I always include a "xx" language with all strings translated to "xxxx", making it easy to spot missed strings. For example, we can see that issue status & "View all" for PRs are not handled:

Here's a dedicated branch in my fork if you want to give a quick look to the xx'ified app :
https://github.com/machour/git-point/tree/xx-hunt-missing-translations

Maybe we could add this for non-release mode, and have the xx variable populated dynamically when picked so that we don't have to keep syncing its file?

Also, it may be good to setup some kind of conventions for translations, like having all translators maintaining a comment in their language file that including the en.js commit hash at the time they updated their translations :

/* in sync with 1deae96 */
export const fr = {
  ...

This would allow to know if the translation is supposedly up to date by comparing that comment with the current en.js commit hash, and if different, diff en.js with that last noted hash (instead of having to check all strings again)

Or maybe I'm unaware of the react way of doing all that I'm suggesting ? 😅

[1] - Sorry @Antoine38660 I didn't see this issue before 🤗

[andrewda]

Random thought, but do we want to make the m, h and d after times localized, too? Or is that pretty standard in non-english countries?

[andrewda]

Also, it may be good to setup some kind of conventions for translations, like having all translators maintaining a comment in their language file that including the en.js commit hash at the time they updated their translations :

/* in sync with 1deae96 */
export const fr = {
 ...

This would allow to know if the translation is supposedly up to date by comparing that comment with the current en.js commit hash, and if different, diff en.js with that last noted hash (instead of having to check all strings again)

We should be able to check these keys programmatically pretty easily – just make sure Object.keys(language_object) is equal for all of them. I can write up a quick test to make sure they're all in sync, and fail otherwise.

[machour]

@andrewda yes, m, h and d should definitely be translated as well (d is j in french for example)

As for comparing the keys, this test wouldn't be enough as the value associated with a key in en.js may evolve as well:

• typo fix : no translation update required
• change of meaning : translation update required

[andrewda]

I think _usually_ if the meaning of a sentence is changed, the key would be changed too. We can definitely do both, though.

[housseindjirdeh]

Thanks a million folks, definitely agree with @andrewda and the easiest way would most probably be a test that compares the object keys for each translation. I'll add the test run step to travis.yml so it's part of the CI

[machour]

Ok for the key comparison, but again, this may not _always_ be enough.
Think of an update to privacyPolicy.userData2 (where the key is not really meaningful).

Anyways, let's roll 😄

[Antoine38660]

So, with this key comparaison, if I add a new translation (key/value) in the en.js file, the TravisCI test will fail because I didn't provide a French, Spanish and Russian equivalent ?

[andrewda]

@Antoine38660 that's the hope!

[machour]

Doesn't seem like a good feature at all, as it will probably result in the developer copy/pasting english text in translations files, or worse, trying to translate using Google Translate or whatever if he doesn't speak natively the X languages.

Better have this comparison feature as a yarn utility, not a test blocking work on the application features.

[housseindjirdeh]

Oh that's a good point @machour 🤔

@Antoine38660 So when we add that test as @andrewda suggested, having a different number of keys will automatically fail. But @machour makes a good point in that it probably would make more sense to also be able to solidify if the actual translation values are up to date for each language.

I think writing up the simple test is a good starting point since it'll be relatively easy to set up. @machour I don't think having the test will result in that specifically, we'll definitely be keeping an eye on PR submissions so people don't just copy/paste english text everywhere. However I actually do think having your suggestion about including a commit hash will be a good addition as well. I'm happy to have that as part of the contributing guidelines as well.

What does everyone think. How does a combination of the two sound?