Internationalization (il8n) in peeringdb

[mcmanuss8]

If we want to have peeringdb reach the entire world, we can't assume everyone speaks english. Strawman steps - needs fleshing out:

0. Decide on the languages we want to support initially
1. Add il8n support for each field, box/widget and dropdown value
2. Translate the above to each defined language
3. Add a language preference for each user under profile. Default everyone to null.
4. Allow guests to switch languages on the fly, default to the user's preferred language if not null

Challenges would be for free form fields like "Notes" - do we allow users to specify notes in each language they would like? Certainly if someone wrote something in a language I didn't prefer to see, but in no other languages, I would want to see it anyway so I could attempt to translate it. A really nice to have would be autotranslation.

[eloos]

On the notes field, possibly the owner of the record can have multiple fields, depending on the language, other users see the notes field with their language or failing that, an auto-translated version. Google translate seems to offer an API and there is a Python module to do so.
What other items are left for the "needs discussion?"

[arnoldnipper]

Ideally you select your language and after that each and everything is in your language

[eloos]

@arnoldnipper that seems to support my proposal to have an auto-translated version of the notes if the original was not in the language that the viewer has selected in the profile? Please confirm
@mcmanuss8 on the languages supported:

• French
• Spanish
• Portugese
• Chinese
• Japanese
• Arabic
• Russian
  How does that sound? I was told there is in fact a community project that does free translations for non-profit community services like ours. Either way first step would be to have the language pack capability deployed

[arnoldnipper]

Does it make sense to pick the top 10 from https://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers?

[arnoldnipper]

• [yes] Do you agree with the approach as outlined by Steve 1-4 (yes/no)
• [yes] do you agree with my proposal for the notes field (auto-translate via external service if default language of the viewer is not available
• [yes] do you agree an object owner should have the ability to provide by themselves the translation for the notes field if they want?

[mcmanuss8]

Hmm.. for the languages the top N worldwide seem sane. I looked at some of our data to see which countries lack peeringdb entries and see significant internet traffic. Depends how we want to look at it - traffic volume or quantity of ASNs w/ more than noise traffic.

By traffic volume:
English
Spanish
Portugese
Arabic
Russian
Estonian
Azerbaijani

By quantity of ASNs w/ non-noise traffic:
English
Russian
Spanish
Korean
French
Portugese
Japanese

[eloos]

@mcmanuss8 I like the approach you took because it makes the choice clear in the scope of an outreach attempt. Chinese (Mandarin) & Hindi can be implemented later in a second phase.
In addition I think everyone should be able to flag the languages they speak, to help users understand in which language they could reach out to their peer.
On the vote:

• [yes] Do you agree with the approach as outlined by Steve 1-4 (yes/no)
  

• [yes] do you agree with my proposal for the notes field (auto-translate via external service if default language of the viewer is not available
  

• [yes] do you agree an object owner should have the ability to provide by themselves the translation for the notes field if they want?
  

[grizz]

1. Add il8n support for each field, box/widget and dropdown value

Agree.

2. Translate the above to each defined language

We should pick one language we can translate to while developing / testing this -- preferably a language from an active volunteer. After it's released and tested more, we can get more translations added.

3. Add a language preference for each user under profile. Default everyone to null.

Could get language from browser locale, maybe null for preferences and if it's null, get from browser?

4. Allow guests to switch languages on the fly, default to the user's preferred language if not null

Seems largely unnecessary, what's the use case?

I'm for adding auto translate for the notes / free form fields, allowing networks to do their own translations adds a fair amount of implementation work for a feature I doubt anyone will use, maybe take a poll of the user base?

[eloos]

@grizz for [4] the use case is that as a company with international operations that has a NOC which can address questions in multiple languages, I want to ensure that every touchpoint I have with partners and customers is professional, if the translation via automated systems yields strange results, I want to be able to set it correctly for those languages in which I as a company do business.
That being said, the notes field supports markdown so I could redirect to my own company website and get the user language from the browser locale. If there is insufficient support for [4], let us fork it out in a different issue and see whether there is future demand.
Likewise we could indeed start with one language to test. Do we already know what that would be?

[grizz]

@grizz for [4] the use case is that as a company with international operations that has a NOC which can address questions in multiple languages, I want to ensure that every touchpoint I have with partners and customers is professional, if the translation via automated systems yields strange results, I want to be able to set it correctly for those languages in which I as a company do business.

4 is Allow guests to switch languages on the fly, default to the user's preferred language if not null,

I believe you're responding to the 5th (unnumbered) one. I see a use case for that, I just highly doubt anyone will use it, agreed on making it another issue and seeing what support there is.

[eloos]

@grizz you are right, so for the actual (4) i indeed don’t think we need to support that. People could still go through their settings page.

[eloos]

My choice

1. Yes (with on the fly changing shifted to another ticket to implement if there is a demand)
2. Languages: first release a known language so we can troubleshoot, afterwards based on list provided by Steve based on quantity ASN
3. Use case multiple notes field => new issue

[mcmanuss8]

Thinking on 3 some more, we might want 2 settings (I know...):

a) Preferred language
b) Language to display if preferred language isn't translated yet

So for example, let's say I prefer Portuguese, but also speak Spanish. We show all known languages in a, and only the ones we have translations for in b. Benefit here is we could capture which languages people prefer. Also, when we add additional translations we could contact anyone with that language as their preferred one to let them know so they can switch over (or do it automagically)
You would only want to show language to display if the preferred language is not one we have a translation for.

[job]

[yes] Do you agree with the approach as outlined by Steve 1-4 (yes/no)
[yes] do you agree with my proposal for the notes field (auto-translate via external service if default language of the viewer is not available
[no] do you agree an object owner should have the ability to provide by themselves the translation for the notes field if they want?

We don't need to do "every thing possible", I think providing a 'autotranslate this' button for the notes field is sufficient to get started. PeeringDB is not a really a textual content management system, and I fear down the road it'll become somewhat of a clutter of information as users fail to keep all their translations consistent.

[karumugham]

Yes - Do you agree with the approach as outlined by Steve 1-4 (yes/no)
Yes - do you agree with my proposal for the notes field (auto-translate via external service if default language of the viewer is not available
No - do you agree an object owner should have the ability to provide by themselves the translation for the notes field if they want?

On the last one, I don't think allowing users to have multiple versions of the same field is a good idea. There could be things like numerical differences due to lack of proper updating, and no longer any single source of truth for that field.

[nopedial]

1. Do you agree with the approach as outlined by Steve 1-4? yes
2. Do you agree with my proposal for the notes field (auto-translate via external service if default language of the viewer is not available? yes
3. Do you agree an object owner should have the ability to provide by themselves the translation for the notes field if they want? no

[mahtin]

• Do you agree with the approach as outlined by Steve 1-4? yes See below for comments on 3.
• Do you agree with my proposal for the notes field (auto-translate via external service if default language of the viewer is not available? no I believe the Instagram/FB method of placing a "translate" button near the text is important. The use maybe fluent in many languages, including the authors language.
• Do you agree an object owner should have the ability to provide by themselves the translation for the notes field if they want? no I believe notes can be in any language today, what we need is to mark the input language (maybe autodetected or based on the authors default language). Then provide a translate button (see 2 above) if the languages don't match.

3. Add a language preference for each user under profile. Default everyone to null.

The browser provides a hint via Accept-Language and W3C provides some input on this subject. However, lets admit it that FB, Google, etc have years and years of experience at coding and dealing with this requirement. Let's see how we go; but lets move forward.

[mahtin]

When it comes to language choice (which is a very different issue than language support); I'd point to ICANN and their choices of languages: (English العربية Español Français Pусский 中文).

From the experience of translating the IPv6 certification site back many years ago, we did the coding and then reached out to end-users to add language packs (using open source language editing package).

This is an important topic to work on
Este es un tema importante para trabajar en.
C'est un problème important sur lequel travailler
Dies ist ein wichtiges Thema, an dem gearbeitet werden muss
Dit is een belangrijke kwestie om aan te werken
Это важный вопрос для
这是一个重要的问题
これは重要な問題です。

[eloos]

@mahtin

Do you agree with my proposal for the notes field (auto-translate via external service if default language of the viewer is not available? no I believe the Instagram/FB method of placing a "translate" button near the text is important. The use maybe fluent in many languages, including the authors language.

So the difference between the proposal and your comment is that the translation action should not be automatic but it should be done after the pressing of a button? How about we auto-translate (most people are not multi-lingual) and we provide a button to see original text instead?

[mahtin]

I think my reservation is that auto-translate is dependent on fully knowing the source & destination languages. I’m happy to do the baby-step of having it be a user-driven event. Once we have experience (and data or feedback), turn we proceed to step two - auto translate.

BTW: I doubt we’ll have many non-English entries until we educate/commmnicate to the user-base. That should not deter us! La vie continue.

[thatchrisp]

Agree entirely with Job on this:

"[yes] Do you agree with the approach as outlined by Steve 1-4 (yes/no)
[yes] do you agree with my proposal for the notes field (auto-translate via external service if default language of the viewer is not available
[no] do you agree an object owner should have the ability to provide by themselves the translation for the notes field if they want?"

[eloos]

Summary of the discussion for the benefit of $vendor being able to provide a quote:

Requirements functionality:

• Add il8n support for each field, box/widget and dropdown value
• Translate the above to each defined language
• Add a language preference for each user under profile. Default everyone to null.
• Notes field will have a translate button, which translates the contents of the notes field to the user's selected language (see the points above). Translation will be done using an external service

Language support:
one none English language should be implemented as reference, additional language packs will come in future releases.

[vegu]

Functionality has been rolled to beta in version 2.9.0, currently still waiting for portuguese language files, so currently only available language is english. Will update once Portuguese files have been rolled to beta as well.

[vegu]

Portuguese locale has been rolled to beta in version 2.9.1

[mcmanuss8]

https://docs.peeringdb.com/translation/ documents how to do these