Closed Bug 756997 Opened 12 years ago Closed 11 years ago

Failure in /testTabbedBrowsing/testNewTab.js with ja locale: Correct tab title - 'New Tab' should equal '(無題)'

Categories

(Mozilla Localizations :: ja / Japanese, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: whimboo, Unassigned)

References

()

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(1 file)

So we have this strange failure when comparing a new tab title with the label as referenced in the tabbrowser properties file. It has been already seen in bug 748299 but I think we should handle that separately. Doesn't seem to be related to the localization somehow because localized content is available in that file.

Correct tab title - 'New Tab' should equal '(無題)'

http://mxr.mozilla.org/l10n-central/source/ja/browser/chrome/browser/tabbrowser.properties

Tim, any idea why the UI shows the English content instead of the Japanese one? I should probably do a testrun on my own with the ja locale.
The interesting fact is that this happens with the ja locale on mozilla-central but not with e.g. de or mozilla-aurora.
Because, we haven't updated l10n on mozilla-central.

http://hg.mozilla.org/l10n-central/ja/summary
http://hg.mozilla.org/l10n-central/ja-JP-mac/summary

We are planning to merge it from aurora 14.0 (or 15.0 that has MPL2 licenced).
Ah ok, so where is the content you are referring to? I have checked tabbrowser.properties but everything has been translated in there. So out of curiosity where is that non-translated entry?

Also I have removed ja from the locales we currently test via Mozmill CI. We can consider to add it back later.
(In reply to Henrik Skupin (:whimboo) from comment #3)
> Ah ok, so where is the content you are referring to? I have checked
> tabbrowser.properties but everything has been translated in there. So out of
> curiosity where is that non-translated entry?

You can see here:
 (central; tabbrowser.properties)
http://hg.mozilla.org/l10n-central/ja/file/default/browser/chrome/browser/tabbrowser.properties
 (central; newTab.dtd)
 [NONE] (was added at 12.0 to en-US, and is fallbacked from en-US)

We are only working on aurora or beta repository for l10n.
So, there is no 'New Tab' entry on our l10n-central/ja repository.
(In reply to Masahiko Imanaka [:marsf] from comment #4)
> We are only working on aurora or beta repository for l10n.
> So, there is no 'New Tab' entry on our l10n-central/ja repository.

Hm, but you are pushing changes to l10n-central or? That's at least what I can see here: http://hg.mozilla.org/l10n-central/ja/

In any way it looks like we have to revise our strategy in testing localized builds on mozilla-central. Probably it's really not that helpful and we should stop it. Axel, what would you say?
Henrik, the latest change I see on l10n-central is a year old.

Sanitizing the list of locales that are built on central is blocked by releng, see bug 657789.
Thanks Axel. So we now have stopped testing l10n stuff for Nightly builds and will concentrate on Aurora only. That would make this bug wontfix.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Well, my fault. So this is not the l10n testrun but the functional testrun. We kinda would like to run those for all locales even for mozilla-central. So it would be kinda appreciated if we can get this inconsistency fixed.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Yeah, thinking of it, no matter if the locale is up-to-date or not, it should find the same tab title. This sounds much more like a problem in the test suite.
Well, this only happens so far for the ja locale. It's not appearing for de and es-ES. So I don't think that this is caused by Mozmill or one of our tests.
Status: REOPENED → NEW
Is there test code that you can point me to to dive in a little deeper?
Attached image screenshot
Here a screenshot by manually running the ja Nightly build with a fresh profile. Pressing Cmd+T on OS X opens a new tab with the 'New Tab' title.
Component: Mozmill Tests → ja / Japanese
Product: Mozilla QA → Mozilla Localizations
QA Contact: mozmill-tests → bugzilla
Can you clarify on what the test is actually testing? Reading http://hg.mozilla.org/qa/mozmill-tests/file/01dbffb740b4/tests/functional/testTabbedBrowsing/testNewTab.js, it's testing that all the various strings encoding "New Tab" are consistent, and in case of Japanese, we're missing a newer version of that string, and thus end up with an l10n-merged literal "New Tab" instead of its Japanese translation?
So that means in ja we have an inconsistency. On one side we fetch the label of the tabbar entry of the new tab which is called 'New Tab'. And we compare it with the property we get from tabbrowser.properties. But in that file the content is translated. So I'm absolutely not sure why 'New Tab' is really displayed when opening a new tab. It should really display the localized content from the tabbrowser.properties file.
The current l10n status is at https://l10n.mozilla.org/dashboard/compare?run=218604, which says that in particular, newTab.* aren't localized on central yet. The string "New Tab" shows up in a few different places, http://mxr.mozilla.org/mozilla-central/search?string=new+tab&find=locales/en-US for a superset.
Axel, would you mind to check the 'de' and 'es-ES' locales? Do those have this string localized so we do not fail?
I don't exactly know which string is used in the UI, but both german and spanish are far more localized, and in particular, have fully localized newTab.*.
Ok, so that seems to be the problem then. In ja tabbrowser.properties has been translated while newTab.dtd is not present. So we have this inconsistency and fail.

Tim, when do we use which property/dtd entity? In the Mozmill test we were using the dtd entity first but that caused failures so we had to change it to the .properties entry. But as it look like it was not the right way?
I guess that the code path changed with the about:newtab design.
That was what we thought it has been fixed over on bug 735883.
I've tried to track it down, but the code has interesting paths. I think we have three at play, http://mxr.mozilla.org/mozilla-central/search?string=%22New+Tab%22&case=1&find=browser%2Flocales%2Fen-US&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central. No better idea than to do a custom build changing all three, and seeing if different code paths hit different "New Tab" sources.
Given the inconsistencies I will mark this bug as blocker for bug 455553.
The newTab.dtd is used for the newtab page's title, only. This will then be shown as the label for new tabs. Ideally we should probably use the value defined in tabbrowser.properties but afaik that's not possible without loading the string bundle and assigning the attribute value at runtime.
Mario, could you please check if this is still a failure?
Flags: needinfo?(mario.garbi)
We haven't seen this with ondemands lately, and I've also checked it locally for all branches with Ja locale:

Esr17 - GREEN
http://mozmill-crowd.blargon7.com/#/functional/report/14f8bc4e22e61353662cded4c285a5f7

Release - GREEN
http://mozmill-crowd.blargon7.com/#/functional/report/14f8bc4e22e61353662cded4c2859f3b

Beta - GREEN
http://mozmill-crowd.blargon7.com/#/functional/report/14f8bc4e22e61353662cded4c2859b5b

Aurora - GREEN
http://mozmill-crowd.blargon7.com/#/functional/report/14f8bc4e22e61353662cded4c2859a8b

Nightly - GREEN
http://mozmill-crowd.blargon7.com/#/functional/report/14f8bc4e22e61353662cded4c2858c6f

I've used a simplified repository of mozmill-tests to cover only this bug since we had Ja runs with ondemand jobs.
Flags: needinfo?(mario.garbi)
Thanks Mario. So lets close it as WFM then.
Status: NEW → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: