Get or set the current, and source languages.
They are registered as environment variables named
TRANSLTR_LANGUAGE, and TRANSLTR_SOURCE_LANGUAGE.
Usage
language_set(lang = "en")
language_get()
language_source_set(lang = "en")
language_source_get()Arguments
- lang
A non-empty and non-NA character string. The underlying language.
A language is usually a code (of two or three letters) for a native language name. While users retain full control over codes, it is best to use language codes stemming from well-known schemes such as IETF BCP 47, or ISO 639-1 to maximize portability and cross-compatibility.
Value
language_set(), and language_source_set() return NULL, invisibly. They
are used for their side-effect of setting environment variables
TRANSLTR_LANGUAGE and TRANSLTR_SOURCE_LANGUAGE, respectively.
language_get() returns a character string. It is the current value of
environment variable TRANSLTR_LANGUAGE. It is empty if the latter is
unset.
language_source_get() returns a character string. It is the current value
of environment variable TRANSLTR_SOURCE_LANGUAGE. It returns "en" if the
latter is unset.
Details
The language and the source language can always be temporarily changed. See
argument lang of method Translator$translate() for more
information.
The underlying locale is left as is. To change an R session's locale,
use Sys.setlocale() or Sys.setLanguage() instead. See below for more
information.
Note
Environment variables are used because they can be shared among different
processes. This matters when using parallel and/or concurrent R sessions.
It can further be shared among direct and transitive dependencies (other
packages that rely on transltr).
Locales versus languages
A locale is a set of multiple low-level settings that relate to the user's language and region. The language itself is just one parameter among many others.
Modifying a locale on-the-fly can be considered risky in some situations. It may not be the optimal solution for merely changing textual representations of a program or an application at runtime, as it may introduce unintended changes and induce subtle bugs that are harder to fix.
Moreover, it makes sense for some applications and/or programs such as Shiny applications to decouple the front-end's current language (what users see) from the back-end's locale (what developers see). A UI may be displayed in a certain language while keeping logs and R internal messages, warnings, and errors as is.
Consequently, the language setting of transltr is purposely
kept separate from the underlying locale and removes the complexity of
having to support many of them. Users can always change both the locale and
the language parameter of the package. See Examples.
Examples
# Change the language parameters (globally).
language_source_set("en")
language_set("fr")
language_source_get() ## Outputs "en"
language_get() ## Outputs "fr"
# Change both the language parameter and the locale.
# Note that while users control how languages are named
# for language_set(), they do not for Sys.setLanguage().
language_set("fr")
Sys.setLanguage("fr-CA")
# Reset settings.
language_source_set(NULL)
language_set(NULL)
# Source language has a default value.
language_source_get() ## Outputs "en"