I am using React and i18next.
We are using graphql and react-i18next and would like to share the same enum across language used and the graphql schema.
Since we want 2x2 letter local, and graphql to not support hyphen in enum. We decided to go with EN_US.
The problem is, when using EN_US format in i18n
i18n
.use(ICU)
.use(HttpApi)
.use(initReactI18next)
.init({
fallbackLng: 'EN_US',
interpolation: {
escapeValue: false,
},
resources: {
'EN_US': { core: EN_US }
},
ns: ['core'],
load: 'currentOnly',
debug: true,
lng: 'EN_US',
supportedLngs: ['EN_US'],
});
When using EN_US I get spammed with
i18next::pluralResolver: no plural rule found for: EN_US
and my ICU translations don't work anymore. so they appear like this {{count, plural, =0{アカウント} =1{アカウント} other{アカウント}} using en-US works and all my ICU are correctly translated.
So it looks like that using unconventional EN_US report warning and break ICU, while using normal en-US works.
Is there a way to make it work with EN_US ? or I need to convert the language to en-US when using i18n
Theoretically, you're not bound to any specific language code format, but if you want to make use of all the in built language features, like proper pluralization and correct fallback resolution, we strongly suggest to use the following iso norm:
lng-(script)-REGION-(extensions)
i.e.
en, en-US or en-GB
zh, zh-HK or zh-Hant-HK
Other examples are listed here: https://www.iana.org/assignments/language-tags/language-tags.xhtml
And more information about the format can be found here: https://www.w3.org/International/articles/language-tags/
Related
Is there a way to handle decoding and encoding using predefined functions in Freemarker Templating Language?
I am trying to encode a string to UTF-8, in Freemarker Templating Language (FTL), are there any predefined functions to do this? From my basic investigation I found there are no functions so far.
You are looking for URL encoding (aka. percent encoding): ${foo?url}. The charset used depends on the url_escaping_charset configuration setting of FreeMarker, so you should set that to UTF-8. (You can also specify the charset like ${foo?url('UTF-8')}, but of course setting this in the configuration is better.)
In the documentation: http://freemarker.org/docs/ref_builtins_string.html#ref_builtin_url
So the question is can I point out that my application supports en-US, en-GB and use for all of them the single resource file?
The intention is that I want my application to be available for all english-speaking countries. But it's meaningless to have different translations, because there are no specific translations.
Does it have a sense considering the mentioned intention to point out all those specific cultures in a manifest?
Yes - just use one English file and make it as default culture. This way even when en-GB is selected, for example, the app will fallback to en-US :)
As for date formatting - just be sure to use CurrentCulture - it gets formatting from the Regional and Number settings (and not CurrentUICulture which is for language needs only). This way people with, say, en-US UI language and Number formatting set to de-DE will still see the app in English but have number formatting as German.
There is a common confusion between CurrentCulture and CurrentUICulture and that Language equals formatting. That's why I see many 12-hour formats throughout Windows Phone/Store apps that simply ignore my Regional settings. A must-read regarding confusion about UI and Number formatting: http://forums.asp.net/post/1080435.aspx
Although the end-problem that this would solve is a TeX one (installing a new font for PDF output), this particular solution that I'm looking for is a Sphinx issue.
Sphinx uses standard LaTeX when making PDFs, which is fine so far, but I need to install a new font and have tried and failed.
I understand this is a far easier process using XeLateX, so would like to know if there is an extension or some way to configure Sphinx to make it use the XeLaTeX builder instead.
I think this boils down to getting in some LaTeX instructions before sphinx starts its work.
At the start of your index.rst, you can add a "raw" entry that's passed verbatim to latex:
.. raw:: latex
\setyournicefontorwhatever(beautiful.ttf)
Does that help to get the correct font in? I'm using raw latex entries myself to remove the section numbers from part of my documentation (\setcounter{secnumdepth}{-1} in a similar "raw" entry).
Also, the Sphinx documentation on build options has some things you can try. The most promising looks to be the documentclass item in the latex_documents setting.
It is possible to allow sphinx to use the xelatex builder by modifying the make file to use xelatex, or simply build the doc in two commands....make latex, then xelatex yourdoc.tex. However it is important to disable a number of packages including: fontenc, inputenc, and babel as these eithier dont work at all or may cause issues in future. I think there may be alternative packages in leiu of babel if you wish. Also xelatex already allows for some (but not all) characters that inputenc[utf8] would normally account for.
Disabling these can be done in you conf.py file, this doc shows a good example of how to do this under "Option for Latex":
https://github.com/jterrace/sphinxtr/blob/master/conf.py
I add the following to conf.py when using xelatex:
latex_elements = {
# Additional stuff for the LaTeX preamble.
'preamble': ''' \usepackage{fontspec} \setmainfont{Times New Roman}
''',
'inputenc': '',
'fncychap': '',
'utf8extra': '',
'times': '',
'babel': '\usepackage{polyglossia}',
'cmap': '',
'fontenc': '',
'releasename': '', }
You have to turn off a lot of the default latex packages because xelatex uses other packages or have the functionality built-in.
As of recent Sphinx versions (tested with Sphinx 4.2.0), yes! Simply add this to your conf.py file:
latex_engine = 'xelatex'
Reference: https://www.sphinx-doc.org/en/master/usage/configuration.html?highlight=latex_engine#confval-latex_engine
Does Expression Engine have a built-in solution for i18n (internationalization)?
I have to build a multi-language site, and would like to know the best approaches in EE for doing so.
There are many ways you can create a multilingual or country-specific site in ExpressionEngine to deliver content specific to each language/country.
The two most popular solutions are summarized from the following ExpressionEngine Wiki articles:
MultiLingual Websites in ExpressionEngine
The basic idea is to present your content in different languages using a combination of URL Segments, custom fields and a bit of PHP.
Advantages
Single entry manages multiple languages
Simple URL structure
As an example, say you have a 3-language site: English (en), Spanish (es) and German (de).
For every piece of content in your site, you'd create a custom field with the language identifier as a postfix (or prefix, whatever you prefer) to the fields.
Your custom field names might look like this:
custom_field_en
custom_field_es
custom_field_de
To switch between languages, simply add a corresponding URL segment (/en, /es or /de) that matches the language:
example.com/template_group/template/en
example.com/template_group/template/es
example.com/template_group/template/de
The main advantage of this approach is that it keeps all versions of your content inside a single entry, making updates and edits easy and consistent.
MultiLingual Websites in ExpressionEngine, Alternative
The alternative approach idea is to create sub-directories for each country, and use ExpressionEngine's path.php Global Variables to hold the country code and/or language as a variable.
Advantages
No PHP needed
No need to keep track of which segment holds the language variable
Elegant URL structure
Using the same 3-languages as an example from the first method, you would create a new directory in the root of your EE install and name it after the country code of the language you want to add:
Your folder structure might look like this:
+ /de
+ /en
+ /es
index.php
+ /images
+ /system
+ /themes
To allow this method work, place a copy of the main index.php inside each of the language directories. You would then modify each file by assigning variables corresponding to each language's directory:
$assign_to_config['site_index'] = 'http://www.example.com/en/';
$assign_to_config['global_vars'] = array(
"country_code" => "en",
"language" => "english"
);
The URLs built will use whatever language/country designation you choose:
example.com/es-MX/template_group/template/
example.com/MX/template_group/template/
The main advantage of the alternative approach is using Global Variables, leveraging the fact they are are parsed very early, and can be used almost anywhere in templates.
See: ExpressionEngine's Parse Order (PDF, 33 KB)
Other Solutions
Embracing the philosophy of ExpressionEngine, the flexibility you're given as a designer/developer allows you to tailor a custom solution that suits your unique needs.
If either of these approaches don't quite meet your needs, you can eaily craft your own method or take a hybrid approach.
With this in mind, a good starting point would be to look into the Multilingual Add-Ons at Devot-ee that may aide in your development.
I have some static resources (images and HTML files) that will be localized. One piece of software I've seen do this is Apache, which appends the locale to the name; for example, test_en_US.html or test_de_CH.html. I'm wondering whether this naming scheme is considered standard, or whether every project does it differently.
While there is no documented standard for naming Localized files, I'd recommend using the format filename[_language[ _country]] where
language is the ISO-639 2 letter language code
territory is the ISO-3166 2 letter country code
For example:
myFile.txt (non-localized file)
myFile_en.txt (localized for global English)
myFile_en_US.txt (localized for US English)
myFile_en_GB.txt (localized for UK English)
Why? This is the most typical format used by operating systems, globalization tools (such as Trados and WorldServer), and programming languages. So unless you have a particular fondness for a different format, I see no reason to deviate from what most other folks are doing. It may save you some integration headaches down the road.
While there doesn't appear to a standard conventions as to where in the file name to place them, the international codes for language (e.g. "en") and region (e.g. "en-US") are both very common and very straightforward. Variations I've seen, excluding "enUS" vs. "en_US" vs. "en-US":
foo.enUS.ext
foo.ext_enUS
enUS.foo.ext
foo/enUS.ext
enUS/foo.ext
…ad nauseum
I personally favor the first and last variants. The former for grouping files by name/resource (good for situations in which a limited number of files need localized) and the latter for grouping files by locale (better for situations with a large number of localized files).
You should always use the "de-facto" standard, which is the unix/posix way with gettext. And you shoud use gettext to make your localization!
Therefore one and only correct way is to use localization naming like this:
en
en_US
en_UK
Some applications and especially Java developers ar sometimes using the en-US (hyphenated instead than underscored) and it is ALL WRONG!!!
gettext standard is this and only this:
locale
|_en_US
|_LC_MESSAGES
|_appname.mo
Where:
locale - Name of the directory, can vary but it is highly recommended to stay with "locale"-name
en_US - Any standard locale like *es_ES*, *es_PT*, ...
LC_MESSAGES - mandatory and cannot be changed!
appname.mo - msgfmt compiled appname.po file (appname is what ever you want)