Make "WordPress is also available in..." string translatable

[SergeyBiryukov]

Migrating from ​#wp18682:

Currently the links to local sites displayed on WordPress.org for international visitors are partly English, partly translated:

WordPress is also available in Русский.
WordPress support forums are also available in Русский.

For better user experience, we should allow l10n teams to translate these strings in Rosetta. Due to different grammatical cases, the language name would probably need a separate context for these links.

[SergeyBiryukov]

vanillalounge in ticket:18682:2:

I would even go so far as to suggest that if, at the end of the language detection progress, the case we arrive at is US English, then show nothing at all. In other words:

• If language is detected:
  • If the string is translated, show that
  • If the string is not translated, show "WordPress is also available in <language-name-in-English>
• Language is not detected, show nothing.

...

ticket:18682:5:

...it's just proper grammar. "WordPress is also available in Русский" is neither correct English, nor is it correct Russian.

[samuelsidler]

Otto's going to take a look at this as part of the i18n work going on, but no promises given that it's not an easy thing to mess with. We'll have to get the strings from somewhere too, which means adding it in GlotPress.

[vanillalounge]

We'll have to get the strings from somewhere

"the string", singular :)

[valeriosza]

Another tip is that whoever accesses in Brazil, always shows the version of the Portugal website. :-(

[Otto42]

The language guessing code is not running within a WordPress context. This makes it extremely difficult to translate. It will need some rewriting of the ajax calls.

@valeriosza : It doesn't really work based on your location, as such. First and foremost, it uses your locale, as sent by your browser. If your web browser knows about Portuguese and sends that as a possible language, then you'll get the Portuguese version no matter where you are. It falls back to an IP check if there is no locale information, but that's pretty inaccurate and the locale is the usual information used.

[valeriosza]

The Browser uses information from pt_BR, which is different from pt_PT not?

[Otto42]

Is your browser sending it with an underscore? Because HTTP_ACCEPT_LANGUAGE is expected to be sent with a dash.

pt-br will get the message:

WordPress is also available in <a href='​http://br.wordpress.org/'>Português do Brasil</a>.

pt_br won't match, so it will notice the pt and find pt-pt instead, and give this:

WordPress is also available in <a href='​http://pt.wordpress.org/'>Português</a>.

[valeriosza]

Sorry for the mistake, my browser uses pt-br actually, and still only appears to pt-pt version, it happens to all people who have talked in Brazil.

[Otto42]

I've made a change to force it to use a case insensitive match on the locale string. It was not recognizing "pt-BR" before, and it should now.

[valeriosza]

Perfect. It Work good.

Thanks

[Otto42]

For better user experience, we should allow l10n teams to translate these strings in Rosetta. Due to different grammatical cases, the language name would probably need a separate context for these links.

Looking at this now, and for the general case of translating these two phrases, I'm guessing that something as simple as:

WordPress is also available in %s.

Where %s is the link and the language name... is probably not good enough. Yes, no? Special cases?

What about something like:

WordPress is also available in %sEnglish%s.

Where we replace the %s's with the A and /A bits, so that the translators can move the link as needed?

What's the correct way to make these phrases so that it can work with all languages and be translatable properly? Input from the polyglots team may be needed.

[nacin]

"WordPress is also available in %s" is fine as long as it is made clear to translators that %s is their language's native name (as dictated by the GlotPress locales file). "WordPress is also available in %sEnglish%s." is bad, and at worst we'd do something like:

/* translators: Insert your language name in place of 'English' */
"WordPress is also available in <a href="%s">English</a>"

Multiple languages can actually be suggested here, based on multiple matches. Might I suggest:

"WordPress is also available in English (Español, Français, Deutsch)"

Essentially, any additional languages are just listed in parentheses after. No need for full sentences here. Each language name would be linked.

[vanillalounge]

+10000 for nacin's solution, assuming this means _e( "WordPress is also available in <a href="%s">English</a>" ) somewhere in the code. I'm just not sure I understand

Multiple languages can actually be suggested here

Who suggests? Or is it detected?

[Otto42]

Detected. Again, mostly based on what the browser sends as far as accepted languages go.

If that's translatable okay, then cool. I'll go that route.

[SergeyBiryukov]

_e( 'WordPress is also available in <a href="%s">English</a>' ) looks good to me.

[vanillalounge]

Sorry for maybe being dense, but where does the Meta .pot live, to be translated?

[nacin]

This wouldn't live in that pot (which doesn't exist). It'd probably get shoved into a Rosetta file so it can be translated there, and then pulled directly from GlotPress on the fly to be served. Well, maybe not Rosetta as that would suggest that deploy requests are needed (when they would not be). We'll find a suitable place.

[vanillalounge]

Of course, meta isn't translated at all, since that is what the Rosetta sites are to begin with. That said, it sort of make sense to have that string in the Rosetta .pot; it is a kind of "embassy" on the main site.

[nacin]

Done. Strings are in translate.wordpress.org/projects/rosetta/forums.

[SergeyBiryukov]

Replying to nacin:

"WordPress is also available in %s" is fine as long as it is made clear to translators that %s is their language's native name (as dictated by the GlotPress locales file).

Unchangeable language name looks a bit weird for languages with declensions (can't use the correct case), but it seems like the alternatives would be much harder to implement, so this should be good enough for now. We just have to translate the rest of the string in a way that makes the most sense.

Still, this is an awesome enhancement, cheers :)