Internationalization/class structure
Class structure
That's a possible structure of the whole thing:
SHARED_I18N_LOCALIZATOR => I18N_LOCALIZATOR => 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 at the end the mo_parser will be used if the string is not already in memory (actually for the initial filling of the datastructure); the plural forms resolver will be used to find out which plural form should be used.
SHARED_I18N_LOCALIZATOR (already in place)
- translator: I18N_LOCALIZATOR
- t(string): STRING
- tn(string, args): STRING (or what you want)
t and tn are interfaces to the translator
I18N_LOCALIZATOR (skeleton already in place)
- 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 (already in place)
- 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 (already in place)
- open(file)
- load(n): STRING
- load_translated(n): STRING
- load_hash_entry(n): STRING
I18N_PLURAL_FORMS (already in place)
- get_plural_form(n): INTEGER
