eaton.alf@ Thanks for the issue.

Able to reproduce the issue on Mac OS 10.13.3 on the reported version 67.0.3396.87, but the issue is not observed on the latest Stable 67.0.3396.99.
Request you to retry the issue on latest stable and let us know if the issue still persists.

You can download latest chrome stable from URL : https://www.chromium.org/getting-involved/dev-channel

Thanks!

Krishna,

You updated the drop that had the incorrect encoding.

I've updated to Chrome 67.0.3396.99 and still see the same encoding error in the menu item.

Still a problem on macOS 10.13.4 and Chrome Canary 69.0.3474.0

I think an email address has been entered in the "status" field of this issue, instead of the "cc" field?

Hi All,

Thanks for raising this bug. 
This is more of a functional case, coding issue. I am not quite sure of a language POC can fix this. I'll be looping in the Engineering Team to assist.

Kind Regards!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+jshin@ (i18n Eng)

Hi All,

I have reported this to the language POC to fix the string.
I'll notify you all once it is done.

Kind Regards!

Thank you!

Removing Needs-TestConfirmation label as per comment #12.

The file containing the error (ui/strings/translations/ui_strings_en-GB.xtb) has been changed, but not corrected. 
Diff: https://chromium.googlesource.com/chromium/src/+/a1981d69db4056f61385a52f0a5fc3d14ac6f891%5E%21/#F432
The string is now displayed as "Emoji  Symbols", instead of the expected "Emoji & Symbols". 
To get the correct behaviour the xtb string should be "Emoji && Symbols". 
I don't know why there need to be two & but I've compiled and tested it and it works, but apparently the change has to be made by a special person. 
Please get it right this time

Hi All,

The string has been fixed as I've checked.
Marking this ticket as fixed.

Regards!

Comment 15 is correct. Reopening.

You need two "&" things in the middle of the string, not just one. Please refer to the en-US string for reference.

Thanks for flagging. This has been forwarded.
I'll update you all for the progress.

Regards!

Hi All,

Please see the response below from en-GB locale:


I'm pretty sure that's how it was originally for en-GB and I was asked to change it. 

I think it would be safer all round if I just changed it to "Emoji and symbols" to avoid any display issues. Would you agree? 

Almost all other languages use their word for "and" rather than an ampersand, e.g. French uses "Emoji et symboles". 

Please advise.

Let's back up.

> I'm pretty sure that's how it was originally for en-GB and I was asked to change it.

Alas, no.

This string in en-US is written "Emoji && Symbols" and displayed as "Emoji & Symbols".

This bug was that it was localized as "Emoji && Symbols" which displayed incorrectly. It was changed to "Emoji & Symbols" which *still* displays incorrectly.

If you think it best to use "and" here, we can change it across all en locales for consistency. Otherwise the simple fix it to just plug in the string "Emoji && Symbols" to match en-US.

Regarding the change from '&' to 'and'. 
In the ui_strings.grd file the emoji string has been divided into macOS and not macOS platforms with the note saying "The context menu item to display the OS-provided emoji picker."(https://cs.chromium.org/chromium/src/ui/strings/ui_strings.grd?q=Emoji&l=510)
Somehow I interpreted it as meaning that it should be named after the string for the native button to open the emoji picker. I realise now that I might have interpreted that wrong, but I couldn't find any reason to name them different things for different platforms. 

The native string in macOS use '&'. 
Personally I think 'and' would be better though. 
Thoughts?

If we're going to the trouble of doing "if Mac" to give the Mac its own string, let's exactly match them.

Hi All,

They have updated it now as what was requested.

Please let me know via this bug if that display correctly or if they should change it to "and" instead.

Regards!

I have to wait until the string sync; will get back to you.

 Issue 860672  has been merged into this issue.

Translation extraction/dump completed, pls check now.

Pls request a merge to M68 if needed. Thank you.

https://cs.chromium.org/chromium/src/ui/strings/translations/ui_strings_en-GB.xtb?type=cs&q=5463830097259460683&g=0&l=93
<translation id="5463830097259460683">Emoji &amp;amp;&amp;amp; Symbols</translation>

It is broken again.

Is the TC incapable of what we need it to do!?

No, the TC is fine.

https://cs.chromium.org/search/?q=%26amp;%26amp;+5463830097259460683&type=cs

The ampersands are correct in ta, te, id, ko, ms, mr, vi, and de.

They need to be correct in en-GB.

 jshin@/melliem@/srahim@, could you ptal comment #30 and see what can be done for en-GB?

The original string is Emoji && Symbols:

https://cs.chromium.org/chromium/src/ui/strings/ui_strings.grd?rcl=58a1bf4b447082c35058966ecf45abd86bf8f6e7&l=516

In TC, for en-GB, it's "translated" into ( http://shortn/_MDL8eoibGG )

Emoji && Symbols

For Indonesian, the 'translation' is ( http://shortn/_Ujwwt9Zdh8 )

Emoji && Symbols . 

 



I think it's a 'mistranslation' in en-GB. en-GB has literal '&&' instead of '&&'. 
I made a suggestion to make en-GB like Indonesian.

It seems like the TC automatically does the handling of the entities. I agree with jsin; en-GB should do whatever id is doing.

ramyan@:  a question about your change at https://chromium-review.googlesource.com/c/chromium/src/+/999008 .  Could you tell us why you used '&&' instead of '&" (singple ampersand) ?  

&& works, & doesn't.

See comment 15 in this bug. If you use just one "&" then it doesn't show up, as "&" is a marker for the accelerator shortcut in a menu.

Ok. Thanks. I'll just override in TC to have '&&' (literal).  That should fix en-GB. 

I don't know how strings for branches are handled. If necessry, xtb file for en-GB can be directly edited in Chromium tree for branch cherry-pick. 

Regarding the question in comment #35: avi@chromium.org has the correct explanation in comment #36. '&&' is required to escape the '&'

BTW: we used 'Emoji & Symbols' rather than 'Emoji and Symbols' because the former is the text in Mac's native Edit menu.

 Issue 862570  has been merged into this issue.

Yes! 69 is fixed.

It probably makes sense to hand-fix this on 68 and maybe 67.

This bug requires manual review: We are only 11 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+Yana FYI

Krishna - an you please advise whether it's safe to merge this back into 68? It's now been an issue on Mac since we launched M67 so it'd be nice to not have En-GB users wait an entire milestone for a fix, but I prefer we don't break the build.

AFAIK, the change was from TC side so no merge to M68 is needed. This should be fixed in 68.0.3440.60+ as I ran full translation extraction/dump process on M68 yesterday.
jshin@, pls correct me if I'm missing anything here.

+manoranjanr@ to get this verified by test team on latest canary and 68.0.3440.60+.

Yes! I see the fix in https://chromium.googlesource.com/chromium/src/+/68.0.3440.60/ui/strings/translations/ui_strings_en-GB.xtb . As long as we do one more respin (68 is at 68.0.3440.59 right now) we'll be great.

Thank you avi@ for confirmation at #45. Next M68 Beta release will be on Wednesday, 07/18 which will include this fix.

Thanks for catching & fixing this!

I was able to repro the issue on market beta 68.0.3440.59 on Mac OS 10.13.3 by passing- defaults write com.google.Chrome AppleLanguages '(en-gb)' from the command terminal and launching chrome.


Verified on the latest M-68(68.0.3440.61) and this seems to be working fine there. No new canary is available due to Issue 863288 to verify the same in M-69.

Attaching the screenshots and adding the verified label for M-68.

Deleted: 856183.jpg 361 KB

	856183.jpg 361 KB View Download

Please mark OS

No merge needed as listed in comments above. 

The "&" is only present in the Mac version of the string.

Fixed on the latest Mac canary(10.13.3) 69.0.3493.0 as well.