Open helen opened 10 years ago
If these are "only" 6 strings, then I would recommend to include them into the core language files - if it would be possible via wp_localize_script() or so. Makes no sense for me to have those as extra lang file for this JS.
I just looked up "my" example, the German localization here: https://github.com/ivaynberg/select2/blob/master/select2_locale_de.js
--> It has at least one string that contains a personal pronoun - which is regarding formal/ informal translations for languages that have this, for example German. Because of that including all those strings in core language files makes a lot of sense!
--> Having those .js string files would only make sense for me if those are generic, timeleless strings not regarding any personal pronouns.
So translators would translate these strings specifically for WP? I don't think it's a big deal, just wondering. I guess we do the same thing for MediaElement, which has a lot more strings, in any case.
So - looks like we should do a wp_localize_script( 'wp-select', '_wpSelectL10n', $strings );
kind of thing (naming just made up, not sure what to name this yet).
Was not aware of the MediaElement practice - so in that bigger picture it totally makes sense to have some kind of the same practice for each of those libraries. My above suggestions were more from an end user and translators point of view.
However, your approach wp_localize_script( 'wp-select', '_wpSelectL10n', $strings ); looks good to me :) Thanks!
Select2 has dynamic strings. for example:
function formatMatches(matches) {
if (matches === 1) {
return "One result is available, press enter to select it.";
}
return matches + " results are available, use up and down arrow keys to navigate.";
}
and compare that to the Ukranian:
function formatMatches(matches) {
return character(matches, "результат") + " знайдено, використовуйте клавіші зі стрілками вверх та вниз для навігації.";
}
function character(n, word) {
return n + " " + word + (n%10 < 5 && n%10 > 0 && (n%100 < 5 || n%100 > 19) ? n%10 > 1 ? "и" : "" : "ів");
}
We can either utilize the translations available upstream, or create a Javascript version of our PHP l10n API.
Select2 comes with a significant number of translations, each language as a separate JS file. Should we use these as-is somehow, or should we look at a more "WordPressy" way of handling the strings? If we opt for the latter, how do we keep things in sync, or do we just have translators translate them over again? It is not a large number of strings (6 as of this moment).