[ROOT] / doc / toc / ARCQuery / Class / Translations

ToString

Offers a very simple system for keeping track of translation between different ("western") languages.

(this class has, as of Jan 2022, not been tested for other languages than those using an alphabet similar to the Latin alphabet with left to right direction.)

Various approaches to storing translations are:

Approach 1: Storing translations in the classic PropertyStream:
Recommended prefix is t, translations can then be added like this:
t/de_DE/_Car = Wagen
t/fr_FR/_Car = Auto
t/nb_NO/_Car = Bil
See TryGetPS (but note that it offers a slightly different format).

Approach 2: Storing translation strings directly within C# source code.
For instance a class called "Translations_de_DE.cs" could have an adder method "a" working like this:
a("Car","Wagen");
a("Bicycle","Fahrrad");
(the adder method is then supposed to populate this class).
See TryGetA

Approach 3: Storing translations as -MacroType-.-Translation-.
(requires use of ARCEvent)
This approach makes it possible to choose translation on-the-fly at time of development.
See TryGetMacro

For all three approaches, this class can be put into the global data storage,with prefix t, making translations available to API clients through ordinary queries.

In all cases, this class will add untranslated keys (assumed that they start with an underscore ('_'), with TranslationSingleP.Text set to key (minus the underscore) and IsMissing set to TRUE.

This is accomplished through override of method TryGetP.

These "IsMissing" translations can then be queried, and added either to the property stream or C# source code as suggested above.

That is, translation keys should always start with an underscore ('_').
This makes it possible to use ARCQuery against this class, because keys not starting with an underscore can then be attempted parsed as a query like 'All', 'SELECT *' or similar.

Note that if you are using ARCEvent with exhaustive unit testing, that is, with all possible translation keys being excercised, then this class can be queried afterwards for any missing translations.

Keeping everything in-memory / in C# code has the advantage of not polluting any database with random translation keys that come and go if code is frequently changed. This is because new keys are ephemeral (the exist only within application lifetime).
You then implementing new translation keys only when you know that you have a stabile software configuration, that is, only when you know that the keys that you have are actually permanent.

Also, you can at any time (assumed exhaustive unit testing) query this class for currently in use translation keys, with their translation, and paste that direct into the C# code (replacing the existing code), thereby removing unused keys from the C# code.

Note how inherits PConcurrent in order to work in a multi-threaded context.

Note regarding choice of which AgoRapide library to put this class into:
At time of development, no clear natural home was found for this class.
It was first put into ARCDoc, then ARCQuery because it used QueryExpression.TryParse.
It no longer uses QueryExpression.TryParse, but since it does use the concept of EntityMethodKey, moving back again to ARCDoc looks unnatural (but is quite possible).
Note that this class also refers to ARCEvent in the comments.

See also TranslationsP.

Generated 2024-04-27 00:08:43.580 UTC