Difference between revisions of "Talk:Internationalization/translation function"
(→Globality: Possible structure) |
(→Globality) |
||
| Line 8: | Line 8: | ||
| − | The CLASS_TO_LOCALIZE simply inherits from | + | The CLASS_TO_LOCALIZE simply inherits from our SHARED_TRANSLATOR, which only purpose is to return always the same "translator: TRANSLATOR". 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 (or for the initial filling of the datastructure). |
| Line 34: | Line 34: | ||
MO_PARSER | MO_PARSER | ||
| − | * open(file) | + | * open(file) |
* load(n): STRING | * load(n): STRING | ||
* load_t(n): STRING | * load_t(n): STRING | ||
Revision as of 01:05, 22 May 2006
Globality
That's a possible structure of the whole thing:
SHARED_TRANSLATOR => TRANSLATOR => ARCHIVE => MO_PARSER
- |
CLASS_TO_LOCALIZE
The CLASS_TO_LOCALIZE simply inherits from our SHARED_TRANSLATOR, which only purpose is to return always the same "translator: TRANSLATOR". 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 (or for the initial filling of the datastructure).
SHARED_TRANSLATOR
- translator: TRANSLATOR
- t(string): STRING
- tn(string, args): STRING (or what you want)
t and tn are interfaces to the translator
TRANSLATOR
- archive: ARCHIVE
- ask(string): STRING (simple interface to ask the ARCHIVE)
- solve_template(string, args): STRING (function that compose a string from template+arguments)
ARCHIVE
- mo_parser: MO_PARSER
- load(n) (interface to the parser)
- get(n): STRING
- data_structure: HASH|ARRAY (where the strings are effectively stored)
MO_PARSER
- open(file)
- load(n): STRING
- load_t(n): STRING
- load_hash_entry(n): STRING
Only few ideas for the moment, review it and make it better and working! Trosim 21:51, 9 May 2006 (CEST)
