This one was hard to find. It turned out that 'Pestaña' is an image file (not a string !). 

In most cases, 'TAB' was translated correctly except for one (that I filed a bug against internally. It's b/28884177 ). 

The image in question has a resource ID ( IDR_OMNIBOX_KEYWORD_HINT_TAB ). 

The string that uses that image is IDS_OMNIBOX_KEYWORD_HINT

See https://goo.gl/C2GtLg and https://goo.gl/gMsNvj

Hmm..  I don't see any localized image resource for omnibox_keyword_hint_tab.png. 

Aha... Got it. In Material Design, 'TAB' is a string (not an image). Its msg id is IDS_APP_TAB_KEY. And, it's indeed mistranslated in both es-ES and es-419. 

'Tab' (key) is indeed mistranslated. 

ui_strings_en-GB.xtb:<translation id="6659594942844771486">Tab</translation>
ui_strings_es.xtb:<translation id="6659594942844771486">Pestaña</translation>
ui_strings_es-419.xtb:<translation id="6659594942844771486">Pestaña</translation>

Unfortunately, I can't track down this message in Google's internal translation DB. What I found is this one, instead:

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/resources/chromeos/chromevox/strings/chromevox_strings.grd&l=1103

'Description=Tab key' does not turn up the message for IDS_APP_TAB_KEY. 

https://code.google.com/p/chromium/codesearch#chromium/src/ui/strings/ui_strings.grd&l=473

Similarly for Dutch, and possibly other languages too:  issue 618073 .

Assign to Chrome LPM to check/fix.

Internally, http://b/28884177 was filed for Spanish and other languages in Spanish. Spanish linguists did make changes, but I'm not sure if that's the string for this bug (somehow, it's rather hard to find the string in question in our internal database). 

Tina, do you know how to map a msg id in the Chromium tree to our internal message ID?  If I know that, I can track it down internally. 

 Issue 618073  has been merged into this issue.

I found a way to map Chrome's string id to internal string ID. I'll ask translators to fix them. 

rob@, I'll ask Dutch translators to fix them, too. 

Ick. It's more complicated. 

The real issue here is that two distinct strings (one for Aria Role 'Tab' - as in Tab UI element - and the other for 'Tab' key) are unified when sent out for translation. 

According to  bug 618073  (rob@),  the former (Tab UI element) is 'tabbard' in Dutch while the latter (Tab key) is 'Tab' in Dutch. 

So, if we change the former to the latter, we'll break the former.

We have to find a way to block two separate strings in Chrome from being unified. 

Two strings in question are:

https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/chromevox/strings/chromevox_strings.grd?q=IDS_CHROMEVOX_ROLE_TAB&sq=package:chromium&l=1110

https://cs.chromium.org/chromium/src/ui/strings/ui_strings.grd?q=IDS_APP_TAB_KEY&sq=package:chromium&l=407

One more in generated_resources.grd. It's not clear which of two meanings this 'Tab' has. 

https://cs.chromium.org/chromium/src/chrome/app/generated_resources.grd?q=file:generated_resources.grd+Tab&sq=package:chromium&l=491&dr=C


  <if expr="is_macosx">
        <message name="IDS_ACCNAME_TAB" desc="A generic description of a tab button's role">
          Tab
        </message>
      </if>

Ok. The 3rd one should be 'Tab UI element' given how it's used in the source.

 if ([attribute isEqual:NSAccessibilityRoleDescriptionAttribute])
    return l10n_util::GetNSStringWithFixup(IDS_ACCNAME_TAB);

Opensource message ID (in chromium repository's xtb files) is generated 
by GenerateId ( https://goo.gl/qb8CU1 ) 

 # Generate an id by hashing message content
  def GenerateId(self):
    self.SetId(GenerateMessageId(self.GetPresentableContent(),
                                 self.__meaning))
    return self.GetId()

As can be seen above, 'meaning' is taken into account but 'description' is not. 

The vast majority of messages do NOT have 'meaning' while quite a lot of them have 'meaning'.  

Anyway, a simple way to dinstinguish them is to add 'meaning' field in grd. 

Have a fix for this particular issue. 

We may have to think about what to do for other messages. We can change GenerateMessageId to take into account 'desc', but they will change message ids for tons of existing messages. Moreover, they have to be sync'd in the Chromium tree and internal tree used by Chrome team to submit messages to internal translation queue. So, it's very tricky. 

An alternative is to identify messages like 'Tab' and add 'meaning' field. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4b276f44f50714b0a24a290ab58c7caf761fbc1c

commit 4b276f44f50714b0a24a290ab58c7caf761fbc1c
Author: jshin <jshin@chromium.org>
Date: Thu Aug 04 06:08:45 2016

Distinguish identical messages with different meanings

There are three 'Tab' in grd files across Chromium tree. Two of them
refer to a UI element (e.g. browser tab) tab while the third one
refers to Tab key.

Without 'meaning' field in grd, they're unified ('desc' does not
count when calculating a message ID !!) and sent for translation
as one message.

Add 'meaning' field so that the former is distinguished from the latter.

BUG= 613776 
TEST=Message Ids (internal) generated by grd_to_xmb are different. (internal)
TEST=Message Ids (chromium) output by map_id are distinctt. (internal)
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2208433003
Cr-Commit-Position: refs/heads/master@{#409726}

[modify] https://crrev.com/4b276f44f50714b0a24a290ab58c7caf761fbc1c/chrome/app/generated_resources.grd
[modify] https://crrev.com/4b276f44f50714b0a24a290ab58c7caf761fbc1c/chrome/browser/resources/chromeos/chromevox/strings/chromevox_strings.grd
[modify] https://crrev.com/4b276f44f50714b0a24a290ab58c7caf761fbc1c/ui/strings/ui_strings.grd

Translation came back ( project=ChromeClient, internal msgId=3125219921445640453) , but for a lot of languages, translators chose a rather long word instead of what's written on the keycap for 'Tab key'. (I should have written that on the description/meaning). 

For instance, Italian keyboard just has 'Tab' ( http://ascii-table.com/keyboard.php/142 ), but Italian translation is "Tabulazione". 
Both Spanish (es-419 and es-ES) have 'tabulador'. 
German is now 'Tabulatortaste'.

Perhaps, they're ok although not optimal (because they're too long)

 bug 618073  (Dutch) is now correct. It has 'Tab' for 'tab' key. 

French is for sure incorrect. It has 'Onglet' (which is for UI element tab as in browser tab): https://fr.wikipedia.org/wiki/Onglet_(informatique)

am ትር
ar علامة تبويب
bg Табулатор
bn ট্যাব
ca Tabulador
cs Karta
da Tabulatortast
de Tabulatortaste
el Πλήκτρο tab
en-GB Tab
es-419 Tabulador
es Tabulador
et Vahekaart
fa Tab
fil Tab
fi Sarkain
fr Onglet
gu ટૅબ
hi टैब
hr Kartica
hu Lap
id Tab
it Tabulazione

iw כרטיסייה
ja タブ
kn ಟ್ಯಾಬ್
ko 탭
lt Skirtukas
lv Tabulēšanas taustiņš
ml ടാബ്
mr टॅब
ms Tab
nl Tab
no Fane
pl Tab
pt-BR Guia
pt-PT Tabulação
ro Tab
ru Вкладка
sk Karta
sl Zavihek
sr Табулатор
sv Flik
sw Kichupo
ta தாவல்
te ట్యాబ్
th แท็บ
tr Sekme
uk Tab
vi Tab
zh-CN Tab
zh-TW Tab 鍵



Either this string has to be sent again for re-translation or we just have to ask resident linguists to override it with our internal tools if/when necessary. 

ryanm@ : I'm gonna ask for that in http://b/28884177. Could you reach out to all the linguists to take a look at this particular message and override if necessary? 

From those, at least cz and sk is wrong. 

Thanks, kostal.david8,  can you give me the correct translation for cz and sk? Thanks

+ manji@ Chrome LPM to coordinate the translation fixes

manji@: As I wrote in http://b/28884177, there are quite a lot of languages with mistranslated strings for either 'Tab' (UI element) or 'Tab' (key). I made suggestions for a few languages, but I'm afraid there are a lot more. So, all the languages for these two messages have to be reviewed and corrected if necessary. 

Thank you

I'm on Chrome OS 52.0.2743.116, with language set to "español (Latinoamérica)" and I see a second problem now: the press-Tab message starts "Haz clic en [Pestaña]..." instead of either "Pulsa [Pestaña]..." (what it was in the initial screenshot for this bug) or "Pulsa [Tab]..." (the corrected version).

"Haz clic en" is "Click on," like with your mouse, and "Pulsa" is "Press," like press a key. Someone should verify but seems like you mean "Pulsa" here.

This is also mistranslated in Russian. 

It was fine before version 51 I believe, but now it says that I should press "Вкладка" (UI tab) rather than "Tab" to search.

 Issue 680179  has been merged into this issue.

Thanks for sending a report. We're internally triaging the bug and we'll update the thread once it's fixed.

 Issue 645339  has been merged into this issue.

 Issue 640670  has been merged into this issue.