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

Reply via email to