Arabic Locale Code
Endike Baur
This is a simple table output of all country locale codes with quick search. You can find your country and locale here.
If the locale code is not mentioned here, you can create it for your case following the instructions.
Staffbase offers various content and interface languages for your employee app or intranet to cater to the multi-language needs of your users. Learn more about the overview of languages for the Staffbase platform.
The Staffbase platform uses locale codes to identify languages for localization purposes and in APIs. You need these locale codes to define the language for your custom-built integrations, such as custom plugins and custom widgets.
This list includes all the languages that the Staffbase platform supports and the corresponding locale codes. Check which languages are supported for the app interface, the Staffbase Studio, and different types of content before using these locale codes.
The JRE and JDK Installers are localized to the languages specified in the User Interface Translation table. The installers will use the use the system's default locale setting to determine which of the supported languages to use at the time of installation. If the system's default locale is not supported by the installer, the installer will be displayed in English.
The support for locale-sensitive behavior in the java.util and java.text packages is almost entirely platform independent, so all locales are supported in the same way and simultaneously, independent of the host operating system and its localization. The only platform dependent functionality is the setting of the initial default locale and the initial default time zone based on the host operating system's locale and time zone.
Numbering systems can be specified by a language tag with a numbering system ID, such as th-TH-u-nu-thai. The following are the available numbering system IDs for specifying a numbering system. No algorithmic numbering systems defined in Unicode Locale Data Markup Language (LDML) are supported.
HOST: This provider enables the default locale(s) (Locale.Category.FORMAT and/or Locale.Category.DISPLAY) utilizing the underlying operating system. This provider is available on Windows platform and Mac OS X platform.
For the Java Foundation Classes (AWT, Swing, 2D, input method framework, drag and drop) and JavaFX, locales can generally be characterized by just the writing system; there are no country or language specific distinctions. Writing system support in the JFC/JavaFX depends to some extent on the host operating system, and full support for simultaneous use of multiple languages is not always possible.
Support for text input consists of two parts: interpretation of keyboard layouts, and text composition using input methods. For interpretation of keyboard layouts, the JDK relies entirely on the host operating system. For text composition using input methods, JDK supports native input methods using the host operating system's input method manager as well as input methods developed in the Java programming language (excluding JavaFX environment).
Locale support in input methods implemented in the Java programming language depends solely on the set of installed input methods, not on the host operating system and its localization. However, support for the use of input methods implemented in the Java programming language with peered components is implementation dependent - see below.
Input methods implemented in the Java programming language are supported in lightweight components (such as Swing text components), but not in peered components (such as AWT text components) or JavaFX nodes.
When using physical fonts, we need to distinguish between simple and complex writing systems. Simple writing systems have a one-to-one mapping from characters to glyphs, and glyphs are placed on the baseline continuously from left to right. Complex writing systems may use different glyphs for the same character based on context, may form ligatures, may be written from right to left, and may reorder glyphs during line layout, or may have other rules for placing glyphs (in particular for combining marks).
The 2D text rendering system supports any combination of simple writing systems and the complex writing systems listed in the table above. Within these limitations, the range of supported writing systems is determined by the font. A single TrueType font might provide glyphs covering the entire Unicode character set and a Unicode based character-to-glyph mapping. Given such a font, 2D can support all simple writing systems as well as the complex writing systems shown in the table above. Other complex writing systems are not supported.
No precise list of supported font rendering locales can be provided since support is largely dependent on the installed platform fonts, and the complex text rendering capabilities of the native platform. However in general this means the capabilities of JavaFX should be similar to those of the platform itself, and for the supported modern desktop platforms this should match or exceed those of the equivalent JFC/Swing text rendering.
The automatic implicit addition of fallback fonts to all FX fonts other than application embedded fonts means that the application should benefit from the broadest locale support no matter which FX font is in use.
Text rendering using the AWT and 2D printing API works to the same extent as text rendering on the screen. Text rendering using the pluggable services printing API depends on the printing service used; the services provided by the JRE work to the same extent as text rendering on the screen.
Applications that need to transfer arbitrary text independent of the host operating system, can do so using serialization: Create a Transferable which supports only one flavor: DataFlavor.stringFlavor. This flavor represents the serialized representation of a String. Make sure that the target supports stringFlavor as well. When the transfer occurs, the AWT will serialize out the String on one end and deserialize on the other. This is much slower than a native platform text transfer, but it will succeed where native transfers may not.
The user interface elements provided by the JRE 8, include Swing dialogs, messages written by the runtime environment to the standard output and standard error streams, as well as messages produced by the tools provided with the JRE. These languages are also supported in JavaFX. These user interface elements are localized into the following languages:
The user interface elements provided by the JDK 8, include messages produced by the tools that are only part of the JDK in addition to the elements provided by the JRE. These languages are also supported in JavaFX. The additional user interface elements are localized into the following languages:
I don't want to have to choose a country e.g. United Arab Emirates etc, as this ties the country code to the locale. Sure, I could strip the country code from the locale code in my app, but then I wouldn't be able to use some country codes in other locales if I wanted too, since I'd be stripping all the country parts away. I might want to support Cantonese and Mandarin for example, and then would need zh-hk, and zh-cn, so in this instance I need the entire code.
I know I can make my own locale code, which is awesome, and this is what I've been doing.
But if you do this you lose the ability to have flags, so maybe we could have an option to choose our own flag for the custom locale? As when you are on the list view and only see flags, this becomes very useful.
Also, by using custom locales, we would lose any locale specific options that may be present in the editor. For example, in Contentful, if you choose any Arabic locale (e.g. 'ar'), then in the WYSIWYG editor the RTL rules are applied by default. This is quite good implementation of the locale/RTL logic, because then you don't need to worry about formatting the RTL content, it's automatically applied in the editor, including lists : )
The importance of locales is that your environment/os can provide formatting functionality for all installed locales even if you don't know about them when you write your application. My Windows 7 system has 211 locales installed (listed below), so you wouldn't likely write any custom code or translation specific to this many locales.
The accepted answer misses some rather significant locales. For example, the Chinese locales don't distinguish between the different scriptures (simplified han, traditional han). What's a main-land Chinese citizen who wants traditional han supposed to use - the Hong Kong setting?
I've taken this list of iOS locales, removed the strange POSIX entry, formatted it as Javascript and sorted it by value (so if you use an ordered object implementation and create a list by going through the keys and returning the value, it will show the human readable text in correct order). Also, this list both contains a main entry per language as well as all the region specific variants - this way you always have a designated fallback option, say if your interface has only defined the 'en' option - you wouldn't otherwise know on what to fall back on reliably.
"Language tag syntax is defined by the IETF's BCP 47. BCP stands for 'Best Current Practice', and is a persistent name for a series of RFCs whose numbers change as they are updated. The latest RFC describing language tag syntax is RFC 5646, Tags for the Identification of Languages, and it obsoletes the older RFCs 4646, 3066 and 1766.
While accepted answer is pretty complete (I used myself in similar question that arised to me), I think it is worth to put the whole supported language codes and variations, as well as encodings, and point user to a file which is present in almost any linux distributions, in case he simply wants a quicker answer and no internet for example.
c80f0f1006