On Wed, 26 Nov 2008, Mindaugas Kavaliauskas wrote: Hi Mindaugas,
> One more remainder about i18n. We had a large discussion about i18n > internals, but that about it's public API? We have __*() functions: > __I18N_SAVE() > __I18N_LOADFROMMEMORY() > __I18N_LOAD() > __I18N_GETTEXT() > xHarbour has: > HB_I18NLOADTABLE() > HB_I18NSORTTABLE() > HB_I18NSAVETABLE() > I18N() > HB_I18NSETPATH() > HB_I18NGETPATH() > HB_I18NSETLANGUAGE() > HB_I18NGETLANGUAGE() > HB_I18NGETLANGUAGENAME() > HB_I18NGETBASELANGUAGE() > HB_I18NGETBASELANGUAGENAME() > HB_I18NSETBASELANGUAGE() > HB_I18NINITIALIZED() > Current __*() prefix makes me understand, it is not the final version. I > would like to have final implementation of it. What should be the final > public API for i18n? First we should agree final version and resolve some problems. 1. how to keep translation in memory. IMHO it should be single serialized item and hash item is very good choice because it can be also easy extended to keep additional attributes. All translation strings will be indexed by string items and all other attributes like information about CP encoding, language name will be indexes by numbers. F.e.: #define HB_I18N_CPID 1 #define HB_I18N_DOMAIN 2 [...] hTrans[ HB_I18N_CPID ] := "PLISO" 2. how to keep translation in final binary files. hb_itemSerialize() seems to be natural form 3. we should add API to easy create/update trnalsation tables. It does not have to be optimized for speed and can be written as .prg code so programmers can easy create usr interface for translations in their programs. We can also create such program as new hbtools, f.e. hbi18n so it can be used externally to application. To not hardcode internal representation in such programs we will need functions to initialize new translation set, add new translation item and extract final set as item or string. 4. We should add support for loading directly .pot files and create translation table from them. 5. For easy use it's necessary to have in core code function which will work like printf(). Otherwise it will be hard to create strings for translations which are not context dependent. Such function should be in base escape characters like %s or %d compatible with C so we can use dedicated tools to operate on .pot files. Anyhow for better flexibility we should add support for stringify and format any item size. F.e. %s should also work for numeric, date and logical items. In general it should be possible to create formatting similar to the one given by transform and picture clasue. We can add support for passing picture clase directly in formatted string or as parameter. We can also add some additional extensions. The function name is less important. We can call it hb_strFormat(). It's time to implement it. 6. We should decide if we want to add support for plural form translations. Now it's not supported by us. In many cases we can live without it but sometimes it's useful. It will be important for final translation representation though seems that if we will use hashes then it can be added later. We can simply add translation for plural forms as additional hash item attributes. 7. We should give more precise meaning for domain names in our implementation. I think that using it as language ID is quite good idea. 8. The C interface should allow to use different low level implementation so if someone will want to use real gettext API then it can register his own wrappers. 9. We should add support for automatic CP translations in output strings. Otherwise we will end with many different lang modules for different encoding like in msg*.c files. There is a question if we also want to add translation for input strings but I do not think it's very important. We can leave it open for future decissions. 10. We should decide about global settings which will control the translation module: - default domain/language - default path with translation file If we want to make them thread local then they should be controlled by _SET_* structure. In such case they will be inherited by child threads. I can implement the base C code when I'll hear your opinion about above points. It will be good if you or someone else can work on hb_strFormat() and hbi18n tool for creating translation. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour