<i18n dev> RFR: 8356980: Better handling of non-breaking space

Naoto Sato naoto at openjdk.org
Wed May 14 17:36:51 UTC 2025


On Wed, 14 May 2025 17:18:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:
>> 
>>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
>>> 38: 
>>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:
>> 
>> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
>> But I think you know that ..  since you commented on the PR
>> 
>> The fix was done by @justin-curtis-lu and reviewed by
>> @naotoj so I think I'd like to get their opinion on this
>
> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)

I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089424644


More information about the i18n-dev mailing list