doc(localization): first draft [Solves #132]

[hleb-rubanau]

No description provided.

[hleb-rubanau]

Question from @aldum :

• ["exercise.find_key.prompt"] - these are literal keys, no hierarchy on the
  data structure level, right?

[hleb-rubanau]

I think actual best practice is three-layered:

1. Translating: both nested and flat structures are allowed, i.e. two following approaches are equivalent:

excercise:
  find_key:
     prompt: value # naturally represents namespaces, best choice for big scopes of i18n pieces

excercise.find_key.prompt: value # also allowed, useful for scarce namespaces/thin configs

2. When settings are loaded:
   Merge and resolve all i18n config pieces into a single structure -- either hierarchical structure or one with flattened keys (whatever suits best for internal representation and faster lookups -- most likely, flattened keys are)

3. Lookup: use flat keys only, i.e. t("excercise.find_key.prompt"), and let translation engine to map key to its internal representation.

Lookup by flat keys has great practical bonus: it allows to easily return and display message key itself when nothing is found (or to display some normalized version of message key -- e.g. dots converted to spaces and first letters capitalized). Which is better than nothing and helps to easily troubleshoot malformed message keys.

Also, I must admit that if (most likely) external translators are used, I'd recommend to store translations in e.g. YAML file, rather than pure lua code, and load them into lua tables on initialization. But I am not sure if it meets current architectural vision.