Difference between revisions of "Talk:Internationalization/translation function"

(Globality)
 
(5 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
== Globality ==
 
== Globality ==
That's a possible structure of the whole thing:
+
Content moved to [[Internationalization/class_structure|class structure]]. [[User:Trosim|Trosim]] 12:29, 24 May 2006 (CEST)
  
 +
==Propose==
  
SHARED_I18N_LOCALIZATOR => I18N_LOCALIZATOR => I18N_DATASTRUCTURE => I18N_MO_PARSER
+
As I said, this is only a suggestion, I have syntactical and semantic criticism (tuple, tuple item types, names, plural form,...), too. But I made it to give our group a boost.
::|
+
So '''please''' make some changes and/or criticize my solution!!  [[User:Etienner|<font color="Yellow">'''E'''</font><font color="Black">'''T'''</font><font color="Yellow">'''N'''</font>]] <sup>[[User talk:Etienner|'''<font color="Yellow">talk</font>''']]</sup> 09:00, 25 May 2006 (CEST)
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".
+
Use STRING_32 instead of STRING for output. Use STRING_GENERAL whenever it is possible on input.
 +
--[[User:Manus|manus]] 16:23, 25 May 2006 (CEST)
  
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).
+
== Templates ==
  
 +
A new class (I18N_TEMPLATE_FORMATTER) has been writte by Trosim, but it would be nice to use existing ones. It happens that ST_FORMATTER (part of Gobo) is explicitly excluded from the library, somebody knows the reason?
  
SHARED_I18N_LOCALIZATOR
+
At present when translating a template you must already give the variables that must be substituted. In many situations it is useful to separate translation from variable substitution. This is what I'm working on.
 
+
--[[User:Carlo|Carlo]] 10:32, 10 June 2006 (CEST)
* translator: I18N_LOCALIZATOR
+
:I think we can simply fix this providing two different functions to translate and to substitute the variables, enabling the user to make it in two steps instead of automatically doing that direcly on the localizator's side (I can do that and then we decide what to keep or not). [[User:Trosim|Trosim]] 21:56, 11 June 2006 (CEST)
* t(string): STRING
+
:Other simple solutions (proposed on the mailing list): leave the filling of the template to the programmer, eventually offering the possibility (as of now) to do it automatically. I disagree the refactoring proposed. [[User:Trosim|Trosim]] 11:01, 12 June 2006 (CEST)
* 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! [[User:Trosim|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. [[User:Trosim|Trosim]] 12:25, 24 May 2006 (CEST)
+

Latest revision as of 01:01, 12 June 2006

Globality

Content moved to class structure. Trosim 12:29, 24 May 2006 (CEST)

Propose

As I said, this is only a suggestion, I have syntactical and semantic criticism (tuple, tuple item types, names, plural form,...), too. But I made it to give our group a boost. So please make some changes and/or criticize my solution!! ETN talk 09:00, 25 May 2006 (CEST)


Use STRING_32 instead of STRING for output. Use STRING_GENERAL whenever it is possible on input. --manus 16:23, 25 May 2006 (CEST)

Templates

A new class (I18N_TEMPLATE_FORMATTER) has been writte by Trosim, but it would be nice to use existing ones. It happens that ST_FORMATTER (part of Gobo) is explicitly excluded from the library, somebody knows the reason?

At present when translating a template you must already give the variables that must be substituted. In many situations it is useful to separate translation from variable substitution. This is what I'm working on. --Carlo 10:32, 10 June 2006 (CEST)

I think we can simply fix this providing two different functions to translate and to substitute the variables, enabling the user to make it in two steps instead of automatically doing that direcly on the localizator's side (I can do that and then we decide what to keep or not). Trosim 21:56, 11 June 2006 (CEST)
Other simple solutions (proposed on the mailing list): leave the filling of the template to the programmer, eventually offering the possibility (as of now) to do it automatically. I disagree the refactoring proposed. Trosim 11:01, 12 June 2006 (CEST)