Talk:Internationalization/translation function

Globality

That's a possible structure of the whole thing:

SHARED_I18N_LOCALIZATOR => I18N_LOCALIZATOR => I18N_DATASTRUCTURE => I18N_MO_PARSER

|

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).

SHARED_I18N_LOCALIZATOR

• translator: I18N_LOCALIZATOR
• t(string): STRING
• tn(string, args): STRING (or what you want)

t and tn 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 (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

Only few ideas for the moment, review it and make it better and working! Trosim 21:51, 9 May 2006 (CEST)

Actually part of this structure is already in place, so take care of it when writing the localizator. Trosim 12:25, 24 May 2006 (CEST)