1666675 - The address bar placeholder is in English in a Japanese environment.

Status: RESOLVED FIXED

(Mozilla Localizations :: ja / Japanese, defect)

Description

[Hikaru Terazono]

Attachment: The address bar in Firefox 81.0

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

1. Set a locale to Japanese
2. Open a window

Actual results:

The placeholder text is "Search with Google or enter address".

Expected results:

It should be "Googleで検索、またはURL を入力します" (localized, Firefox 80.0.1).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Drew Willcoxon :adw]

Thanks. Did this work correctly before 81? It may be a regression from bug 1647889.

Comment 3

[Hikaru Terazono]

Attachment: The address bar in Firefox 80.0.1

Comment 4

[Hikaru Terazono]

It worked correctly before 81 (80.0.1, the screenshot above).

Comment 5

[Drew Willcoxon :adw]

OK. It looks like you're using the release version of Firefox 81, not Nightly, correct? Did you enable the browser.urlbar.update2 preference?

I ask because the bug I mentioned, bug 1647889, shouldn't matter on release unless you enabled that preference, because the only effective change that bug made is to call initPlaceHolder when we set search mode to null, but that should never happen on release because we should have bailed out earlier in that method. So if it's not bug 1647889, it's something else.

Comment 6

[Drew Willcoxon :adw]

Never mind, I can reproduce this.

Comment 7

[Hikaru Terazono]

This is the release version of Firefox 81.0, and the browser.urlbar.update2 option is disabled (turning browser.urlbar.update2 on does not change the behaviour).

Comment 8

[Drew Willcoxon :adw]

Gijs, it looks like bug 1645619 may have regressed this. Mozregression produced this pushlog, which unfortunately is pretty big, but that bug looks like the clear culprit: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=02be42e5105ba49e93890fdbd9e24c4f55a9251c&tochange=26de281d4c2171a75d4ad19b07fbd62bd7e69c69

Would you be able to take a look?

Comment 9

[Francesco Lodolo [:flod]]

Unless you can reproduce in a different locale, this looks like a localization error in Japanese :-(
https://hg.mozilla.org/l10n-central/ja/rev/9b2256c9c5752c4c735823cc8759e4b9daeb702e#l5.157

The string is translated, but is the same text as English.

urlbar-placeholder-with-name =
    .placeholder = Search with { $name } or enter address

If this is fixed quickly, it might carry along with a dot release in 81, assuming we need one.

Comment 10

[Francesco Lodolo [:flod]]

I'd expect the translation to be something like this, based on older translations

{ $name } で検索、または URL を入力します

Comment 11

[Francesco Lodolo [:flod]]

In hindsight, but 1645619 should have landed with a migration. I have the feeling the patch started with a completely different approach, not suitable for a migration, and later fell under the radar.

I'm going to write one off-tree, and run it on Japanese, so that we can test Nightly quickly.

Comment 12

[Francesco Lodolo [:flod]]

https://hg.mozilla.org/l10n-central/ja/rev/965fc7a3be8a3e01f76b715b468dd30d4ac8bb60
https://hg.mozilla.org/l10n-central/ja-JP-mac/rev/66ac70c26239908099312c7dc16f3d7e638994fd

Leaving the NI open, mostly to figure how the error happened, and how to avoid it in the future.

Comment 13

[Francesco Lodolo [:flod]]

Attachment: output.html

Once verified in Nightly, we should manually fix l10n-changesets.json on release. New values:

ja -> 965fc7a3be8a3e01f76b715b468dd30d4ac8bb60
ja-JP-mac -> 66ac70c26239908099312c7dc16f3d7e638994fd

This is the diff for ja, between the shipping changeset in 81.0 and the new one (only added strings, plus the fix).

Comment 14

[Masahiko Imanaka [:marsf]]

(In reply to Francesco Lodolo [:flod] from comment #10)

I'd expect the translation to be something like this, based on older translations

{ $name } で検索、または URL を入力します

It's OK. Thank you so much.

Comment 15

[Francesco Lodolo [:flod]]

(In reply to Masahiko Imanaka [:marsf] from comment #14)

(In reply to Francesco Lodolo [:flod] from comment #10)

I'd expect the translation to be something like this, based on older translations

{ $name } で検索、または URL を入力します

It's OK. Thank you so much.

Any idea on how to avoid it in the future? Are you manually copying English strings into the Japanese files?

Comment 16

[Masahiko Imanaka [:marsf]]

Any idea on how to avoid it in the future? Are you manually copying English strings into the Japanese files?

Yes, basically, we are manually copying into Japanese files.
These browser part has been updated by Abe-san. He uses some diff tool (I've heard this before).
In my case, I'm working them line by line, am not using diff tool.
And, we are checking each other work on Github.

If we make a tool to check it (for remaining English words), its code may be complicated.

Abe-san, do you have any idea?

Comment 17

[Francesco Lodolo [:flod]]

This is fixed in Nightly (20200923212316).

@ryan
Could someone (sheriffs/relman) update l10n-changesets.json on mozilla-release for ja and ja-JP-mac? It's not a driver, but it would be a nice ride-along for a dot release, since Japanese is normally fully localized.

The new values are

ja -> 965fc7a3be8a3e01f76b715b468dd30d4ac8bb60
ja-JP-mac -> 66ac70c26239908099312c7dc16f3d7e638994fd

Not sure if there's a better way to manage this type of patches on mozilla-release.

Comment 18

[Francesco Lodolo [:flod]]

[Tracking Requested - why for this release]:
Untranslated address bar placeholder in Japanese.

I marked 82 as fixed, although it will be in the next build. Nightly is already verified as fixed.

Comment 19

[ABE Hiroki (:hATrayflood)]

(In reply to Masahiko Imanaka [:marsf] from comment #16)

Any idea on how to avoid it in the future? Are you manually copying English strings into the Japanese files?

Yes, basically, we are manually copying into Japanese files.
These browser part has been updated by Abe-san. He uses some diff tool (I've heard this before).
In my case, I'm working them line by line, am not using diff tool.
And, we are checking each other work on Github.

If we make a tool to check it (for remaining English words), its code may be complicated.

Abe-san, do you have any idea?

I use graphical diff tool and compare-locales command.
compare-locales notices number of unchanged entities, but does'nt list unchanged entities.
if optional feature that list unchanged entities added to compare-locales, we may avoid this problem.

Comment 20

[Francesco Lodolo [:flod]]

(In reply to ABE Hiroki (:hATrayflood) from comment #19)

compare-locales notices number of unchanged entities, but does'nt list unchanged entities.
if optional feature that list unchanged entities added to compare-locales, we may avoid this problem.

That's unlikely to happen, given compare-locales is in maintenance mode at this point. The easiest way would be to write a parser that exclude common strings (shortcuts, css), and only display a list of strings that are identical.

Note that Pontoon has this feature, but there are a lot of strings to go through
https://pontoon.mozilla.org/ja/firefox/all-resources/?extra=unchanged

It's a bit surprising to see al the SSL errors untranslated.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Sure, we can take this for 81.0.1 should the need for such a release arise (I don't currently have any drivers for a dot release, just FYI).

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/52cca6cf5b8d