gnue/common/doc/technotes 00002.txt

[Arturas Kriukovas]

CVSROOT:        /cvsroot/gnue
Module name:    gnue
Changes by:     Arturas Kriukovas <address@hidden>      02/07/31 10:28:43

Modified files:
        common/doc/technotes: 00002.txt 

Log message:
        Minor changes and updates.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnue/gnue/common/doc/technotes/00002.txt.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gnue/common/doc/technotes/00002.txt
diff -c gnue/common/doc/technotes/00002.txt:1.1 
gnue/common/doc/technotes/00002.txt:1.2
*** gnue/common/doc/technotes/00002.txt:1.1     Thu Jul 18 14:40:47 2002
--- gnue/common/doc/technotes/00002.txt Wed Jul 31 10:28:43 2002
***************
*** 15,93 ****
      source into separate file, then translate it and import back into program.
      Prefered font is unicode, encoding - UTF-8, but while wxPython does not 
      support unicode, 8bit encoding will be used.
!     
!     
      For .py files this can be achieved via pygettext, xpot (po-utils), 
      xgettext or any other program that can create .po files containing
      translatable strings.
      (see http://www.python.org/doc/current/lib/node206.html for details)
      Main idea: to mark string for translation in special way:
        if we have one string to translate and other not to:
!       
!           sstring1="translatable string" 
          sstring2="non-translatable string"
!         
!       we change them into:  
!       
          sstring1=_("translatable string")
          sstring2="non-translatable string"
!         
      That's how it works:
        let's say we have file GBaseApp.py with translatable strings already
        marked for translation - _('translatable string').
        We run
!       
          xpot -d -o GBaseApp.po GBaseApp.py
!       
        result is GBaseApp.po file. In this file are only translatable stings
!       and place for their translation. Then someone does translate these 
        strings and returns us GBaseApp.po file with translations.
        We run
!       
          msgfmt -o GBaseApp.mo GBaseApp.po
!       
        result is GBaseApp.mo file that is prepared for import into project.
      All .mo files are stored in some translation directory, that has
      structure:
!     
        $LC_ALL/LC_MESSAGES/files.mo
!       
      where $LC_ALL is your shell variable - something like en_US (you can 
      look at it running echo $LC_ALL).
      In Linux default directory for this is /usr/share/locale. For GNUe, at 
      least for now, directory /gnue/common/translations is chosen.
      Some example .po files are in translations folder.
!         
  
      .gfd files: user probably will have to create different .gfd files for
      different languages himself, some automated translation may be added 
later.
!     
!     
      This is already finished.
!     
!     
   2. User data - everything that user stores/works with will be stored in 
      unicode (encoded in UTF-8).
!     
      For data that's entered as 8bit encoded data. This was checked with 
      postgresql database, with adapter psycopg and for iso8859-13 encoding and 
it
      worked fine.
      Settings in gnue.conf were:
!     
        # hack for db encoding
        Encoding = iso8859-13
!      
        # Font encoding to be used in forms
        formFontEncoding = iso8859-13
!     
!       
!     Only thing that is not yet allowed - to open form that has some national
!     data strings (like labels).
!         
!     
   3. Regional settings - this is time\date, money and etc. format and other
      country specific data.
!     
      NOTE: maybe it would be better (at least for now - to make things a bit
      simplier) put into gnue.conf something like:
        country=US
--- 15,89 ----
      source into separate file, then translate it and import back into program.
      Prefered font is unicode, encoding - UTF-8, but while wxPython does not 
      support unicode, 8bit encoding will be used.
! 
! 
      For .py files this can be achieved via pygettext, xpot (po-utils), 
      xgettext or any other program that can create .po files containing
      translatable strings.
      (see http://www.python.org/doc/current/lib/node206.html for details)
      Main idea: to mark string for translation in special way:
        if we have one string to translate and other not to:
! 
!           sstring1="translatable string"
          sstring2="non-translatable string"
! 
!       we change them into:
! 
          sstring1=_("translatable string")
          sstring2="non-translatable string"
! 
      That's how it works:
        let's say we have file GBaseApp.py with translatable strings already
        marked for translation - _('translatable string').
        We run
! 
          xpot -d -o GBaseApp.po GBaseApp.py
! 
        result is GBaseApp.po file. In this file are only translatable stings
!       and place for their translation. Then someone does translate these
        strings and returns us GBaseApp.po file with translations.
        We run
! 
          msgfmt -o GBaseApp.mo GBaseApp.po
! 
        result is GBaseApp.mo file that is prepared for import into project.
      All .mo files are stored in some translation directory, that has
      structure:
! 
        $LC_ALL/LC_MESSAGES/files.mo
! 
      where $LC_ALL is your shell variable - something like en_US (you can 
      look at it running echo $LC_ALL).
      In Linux default directory for this is /usr/share/locale. For GNUe, at 
      least for now, directory /gnue/common/translations is chosen.
      Some example .po files are in translations folder.
! 
  
      .gfd files: user probably will have to create different .gfd files for
      different languages himself, some automated translation may be added 
later.
! 
! 
      This is already finished.
! 
! 
   2. User data - everything that user stores/works with will be stored in 
      unicode (encoded in UTF-8).
! 
      For data that's entered as 8bit encoded data. This was checked with 
      postgresql database, with adapter psycopg and for iso8859-13 encoding and 
it
      worked fine.
      Settings in gnue.conf were:
! 
        # hack for db encoding
        Encoding = iso8859-13
! 
        # Font encoding to be used in forms
        formFontEncoding = iso8859-13
! 
! 
   3. Regional settings - this is time\date, money and etc. format and other
      country specific data.
! 
      NOTE: maybe it would be better (at least for now - to make things a bit
      simplier) put into gnue.conf something like:
        country=US
***************
*** 96,106 ****
      and to load settings according to it.
      Later it will be possible to take that data from operating system (?),
      but for now i think this solution will go just fine.
!         
  Used files:
    *  all .py files that have some strings for final user.
    *  all files in gnue/common/translations.
    *  gnue/common/utils/create-po.sh - script to create gnue.po file from all
       .py files.
  
! ---END---    
--- 92,102 ----
      and to load settings according to it.
      Later it will be possible to take that data from operating system (?),
      but for now i think this solution will go just fine.
! 
  Used files:
    *  all .py files that have some strings for final user.
    *  all files in gnue/common/translations.
    *  gnue/common/utils/create-po.sh - script to create gnue.po file from all
       .py files.
  
! ---END---