Internationalization/class structure
Class structure
Warning: We are refactoring the whole thing, more infos coming soon.
That's the actual structure of the whole thing:
SHARED_I18N_LOCALIZATOR => I18N_LOCALIZATOR => I18N_TEMPLATE_FORMATTER, (I18N_DATASTRUCTURE => I18N_MO_PARSER, I18N_PLURAL_FORMS)
- ^
- |
CLASS_TO_LOCALIZE
The CLASS_TO_LOCALIZE simply inherits from our SHARED_I18N_LOCALIZATOR, which only purpose is to return always the same "localizator: I18N_LOCALIZATOR".
This class will in turn ask the archive for the translated strings and then pass it, along with all the arguments, to the template formatter, which will produce the final displayable string.
The datastructure will use the mo_parser for the initial filling of the datastructure (proposal: do it incrementally); the plural forms resolver will be used to find out which plural form should be used.
All this structure is already in place; we don't know yet how to open the right file, should be implemented by an environment variable or for example with a drop-down menu in the configuration dialog?
SHARED_I18N_LOCALIZATOR
- translator: I18N_LOCALIZATOR
- i18n(string): STRING
- i18n_comp(string, args): STRING (or what you want)
i18n (i18n_pl) and i18n_comp (i18n_comp_pl) are interfaces to the translator
I18N_LOCALIZATOR
- archive: I18N_DATASTRUCTURE
- ask(string): STRING (simple interface to ask the archive)
- solve_template(string, args): STRING (function that compose a string from template+arguments)
I18N_DATASCTRUCTURE
- mo_parser: I18N_MO_PARSER
- load(n) (interface to the parser)
- translate(STRING): STRING (interface to the I18N_LOCALIZATOR)
- data_structure: HASH|ARRAY (where the strings are effectively stored)
I18N_MO_PARSER
- open(file)
- load(n): STRING
- load_translated(n): STRING
- load_hash_entry(n): STRING
I18N_PLURAL_FORMS (more on this here)
- get_plural_form(n): INTEGER (interface to the datastructure)
I18N_TEMPLATE_FORMATTER
- solve_template(a_template: STRING_32; a_args: TUPLE): STRING_32 (interface to the localizator)
