Localize add-on #5

rugk · 2020-11-28T20:27:34Z

This first localizes the options page. I had one problem with a non-breaking space, but I could fix that by myself.

I suggest we review any change before pushing to the main branch, @tdulcet. Later I may also protect the main branch before we do any release to enforce this. (For now for small fixes that really need no review pushing to the main branch is okay, IMHO.)

I guess you are a native speaker of English, so feel free to review the English parts.
(I doubt you can review the German parts, so you can ignore them, if you cannot. :) )

—

TODO:

We also need to localize the context menu. In the UnicodeFontHandler you seem to create the titles dynamically. This is of course clever and okay in general, however, obviously needs to be changed now. Also pay attention to how the keys in the messages.json are currently named – you can build that dynamically, but yeah.
What we'd need to decide is whether we write the camelCaseStyle e.g. in the translation file directly or not. At least for the casing stuff, I’d tend to write it in there, so translators could choose a different highlighting or so if that is required.
(Also, while you are at it, expand the aid variable, it is way too short and not self-explaining.)

* add English translation as template * add German translation

tdulcet · 2020-11-29T08:47:22Z

I suggest we review any change before pushing to the main branch

That is fine with me.

We also need to localize the context menu

The strings in these two arrays are what need to be localized:

unicodify/src/common/modules/data/Fonts.js

Lines 6 to 21 in fa3fed0

    
           /** 
        
            * Case IDs 
        
            * 
        
            * @public 
        
            * @const 
        
            * @type {Object.<string>} 
        
            */ 
        
           export const caseIds = Object.freeze(["Lowercase", "Uppercase", "Capitalize Each Word", "Toggle Case"]); 
        
           /** 
        
            * Font IDs 
        
            * 
        
            * @public 
        
            * @const 
        
            * @type {Object.<string>} 
        
            */ 
        
           export const fontIds = Object.freeze(["Superscript", "Small Caps", "All Small Caps", "Unicase", "separator", "Serif bold", "Serif italic", "Serif bold italic", "Sans-serif", "Sans-serif bold", "Sans-serif italic", "Sans-serif bold italic", "Script", "Script bold", "Fraktur", "Fraktur bold", "Monospace", "Double-struck", "separator", "Circled", "Circled (black)", "Squared", "Squared (black)", "Fullwidth"]);

Note that since the strings in the second array are converted into the respective Unicode font, they must contain only ASCII characters, so probably will not be translatable into many languages.

What we'd need to decide is whether we write the camelCaseStyle e.g. in the translation file directly or not.

It would be easy to dynamically convert those above IDs into Camel case and then use the i18n.getMessage() API to get the localized string.

Also, while you are at it, expand the aid variable, it is way too short and not self-explaining.

The variable is just those above IDs dynamically converted into Kebab case to use as an index into the changeCase (see here) and font (see here) objects respectively.

tdulcet · 2020-11-29T08:51:58Z

src/options/options.html

+					Only the quotes replacement is done immediately.
+				</span><br>
+					<span class="helper-text" data-i18n="__MSG_optionHelperTextAutocorrectionEmoji__"  data-opt-i18n-keep-children>
+					For Emoji autocorrection, including <code data-i18n="__MSG_optionHelperTextAutocorrectionEmojiColonsCode__">:colon:</code> shortcodes and Emoticons, please also try out our <a href="https://addons.mozilla.org/firefox/addon/awesome-emoji-picker/" data-i18n="__MSG_optionHelperTextAutocorrectionEmojiLinkText__"  data-i18n-href="__MSG_optionHelperTextAutocorrectionEmojiLink__">🤩&nbsp;Awesome Emoji Picker</a> add-on.


While it does not effect this PR, note that the AMO URL will need to be updated after I create the Thunderbird and Chrome PRs for the Awesome Emoji Picker...

Ah indeed, at best dynamically. Yeah, thanks for the notice.

No problem.

rugk · 2020-11-29T14:23:52Z

It would be easy to dynamically convert those above IDs into Camel case and then use the i18n.getMessage() API to get the localized string.

That’s the way to go IMHO then.

The variable is just those above IDs dynamically converted into Kebab case to use as an index into the changeCase (see here) and font (see here) objects respectively

Yeah, we cannot/should not o t6hsi with the translated strings of course. Never use translated strings as IDs… Your hint about nin-Unicode chars in many languages is indeed an important thing to keep in mind, I did not though about this.

rugk · 2020-11-30T16:21:41Z

It would be easy to dynamically convert those above IDs into Camel case

Just looked into it and I doubt it's so trivial. The problem is the Ids in Fonts.js are no IDs, but English strings – some have spaces, some have hyphens etc. with different casing.
IMHO the better way would be: Fonts.jscontains the ID only – it should just folow some srict format, . Each ID may then be easily converted to camelCase or the IDs already are camelCase and we return the translation. I.e. never hardcode translations in the JS files.
fontIds should be the same as fonts. Also for fontIds you can then just do an Object.keys(fonts).

Also, regarding i18n, we should never apply any effects on the localized strings. This should be done to allow translators to translate "superscript" e.g. in Russian (translated with DeepL) to this:

надстрочный индекс (ˢᵘᵖᵉʳˢᶜʳⁱᵖᵗ)

So they can still give an example on how it looks while using their own character set to properly translate the thing.
Do you @tdulcet want to change this?

BTW this line does nothing, at most it logs something to the console.

tdulcet · 2020-12-01T09:58:40Z

Never use translated strings as IDs…

Yes, of course. The IDs would stay the same. The translated strings would only be used for the title that is displayed to the user.

Just looked into it and I doubt it's so trivial. The problem is the Ids in Fonts.js are no IDs, but English strings – some have spaces, some have hyphens etc. with different casing.

Yeah, I only wanted to have one copy of those strings to use for both the IDs and titles, to make this easier to maintain. I was thinking we could use some simple code like this to convert the strings into Camel case:

function camelCase(atext) {
	const [head, ...tail] = atext;
	return head.toLowerCase() + tail.join('').split(" ").map(([h, ...t]) => h.toUpperCase() + t.join('')).join('');
}
// ...
const title = browser.i18n.getMessage(camelCase(id.toLowerCase())) || id;

You could of course use some more complex code with regular expressions like this to also remove the hyphens and parentheses:

function camelCase(atext) {
	const [head, ...tail] = atext;
	return head.toLowerCase() + tail.join('').replace(/(?<=\P{Alpha})\p{Alpha}\S*/gu, ([h, ...t]) => h.toUpperCase() + t.join('')).replace(/\P{Alpha}+/gu, '');
}

Also for fontIds you can then just do an Object.keys(fonts).

Some of the strings are "separator" to indicate that there should be a separator there, so Object.keys() would not work.

Also, regarding i18n, we should never apply any effects on the localized strings.

OK, I thought it would be nice for the users to be able see the effect of the options in their language without the translators having to manually convert anything. For example, if the Russian translator used надстрочный индекс (Superscript), it would automatically convert to надстрочный индекс (ˢᵘᵖᵉʳˢᶜʳⁱᵖᵗ).

BTW this line does nothing, at most it logs something to the console.

No, it converts the Font strings into an array symbols using Array.from() for use by the changeFont() function. Array.from() is a new ES 6 feature to properly split Unicode strings (see here and here). Try logging the fonts object before and after that line to see the difference.

Let me know if you need me to make any changes.

rugk · 2020-12-01T14:14:52Z

thinking we could use some simple code like this to convert the strings into Camel case:

Sorry but "simple"? The code you presented there is really long and one really needs to think about it to get what it does… 🙃

Some of the strings are "separator" to indicate that there should be a separator there, so Object.keys() would not work.

Well object.keys and then just filter.

No, it converts the Font strings into an array symbols using Array.from() for use by the changeFont() function. Array.from() is a new ES 6 feature to properly split Unicode strings (see here and here). Try logging the fonts object before and after that line to see the difference.

I did not test, but actually should not make a difference. Array.from "creates a new, shallow-copied Array instance from an array-like or iterable object", i.e. it returns the new array. It does not modify the existing one. So you need to assign the result somewhere…

rugk · 2020-12-01T14:44:25Z

Ah sorry, indeed it assigns thing in fonts[key] = , sorry I have missed that. Well, could need some explanatory comment or put it into a function or so.

tdulcet · 2020-12-02T09:50:35Z

Sorry but "simple"? The code you presented there is really long and one really needs to think about it to get what it does… 🙃

Oh, sorry. I edited my post and changed the code to make it more general after I wrote that. Here is the original simpler version, which assumes the string is lowercase.

function camelCase(atext) {
	const [head, ...tail] = atext.split(" ");
	return head + tail.map(([h, ...t]) => h.toUpperCase() + t.join('')).join('');
}

Well object.keys and then just filter.

Some of the strings in the fontIDs array are "separator" to indicate that there should be a separator (see here). Using Object.keys() on the fonts object would eliminate all the separators from the menu. It also would be a lot more difficult to then dynamically generate the titles from the Kebab case IDs.

rugk · 2020-12-02T10:29:12Z

Well… in any case it needs to be changed, because…

Yeah, I only wanted to have one copy of those strings to use for both the IDs and titles, to make this easier to maintain.

This assumption/aim is not there anymore if we localize. We should kjeep all strings in the messages.json and the code should only contain IDs of some sort.

tdulcet · 2020-12-03T04:00:28Z