#106 closed defect (bug) (fixed)
Make "WordPress is also available in..." string translatable
Reported by: | SergeyBiryukov | Owned by: | |
---|---|---|---|
Milestone: | Priority: | low | |
Component: | General | Keywords: | |
Cc: |
Description
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.
Change History (23)
This ticket was mentioned in IRC in #wordpress-meta by sams. View the logs.
11 years ago
#3
@
11 years ago
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.
#5
@
10 years ago
Another tip is that whoever accesses in Brazil, always shows the version of the Portugal website. :-(
#6
@
10 years ago
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.
#8
@
10 years ago
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>.
#9
@
10 years ago
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.
#10
@
10 years ago
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.
#12
@
10 years ago
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.
#13
follow-up:
↓ 22
@
10 years ago
"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.
#14
@
10 years ago
+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?
#15
@
10 years ago
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.
#16
@
10 years ago
_e( 'WordPress is also available in <a href="%s">English</a>' )
looks good to me.
#17
@
10 years ago
Sorry for maybe being dense, but where does the Meta .pot live, to be translated?
#18
@
10 years ago
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.
#19
@
10 years ago
Of course, meta isn't translated at all, since that is what the Rosetta sites are to begin with. That said, it sort of makes sense to have that string in the Rosetta .pot; it is a kind of "embassy" on the main site.
#21
@
10 years ago
- Resolution set to fixed
- Status changed from new to closed
Done. Strings are in translate.wordpress.org/projects/rosetta/forums.
#22
in reply to:
↑ 13
@
10 years ago
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 :)
vanillalounge in ticket:18682:2:
...
ticket:18682:5: