[FR-devel] FreeRIDE I18N [was: Very alpha version of FR debugger inCVS]

[Curt Hibbs]

I'm going to leave you original text below for reference and add all my
comments here at the top, because most of my comments are about additions,
not changes.

Overall, it looks pretty good (I see one problem, more on this in a moment).
I like the flexibility of using different types of storage containers for
the language db (although, for expediency, you should choose only one to
implement initially -- I'd vote for XML).

My single issue is illustrated by this code sequence:
        # create the local plugin language db
        langdb = LanguageRepository.new("xml", "./myplugin_langdb.xml")
        L = langdb.Language("myapp")
        L.select("en-us");

This implies that all the possible languages for a given plugin (or for the
global FreeRIDE) are contained with one file (in this example,
"./myplugin_langdb.xml"). But doing this would make it very difficult and/or
impossible for an independent party to produce a specific language
translation at a later date. It also makes hard to have independently
downloaded "language packs" -- I may want Spanish, Thai, and English, but
not the other 58 languages in which FreeRIDE is available (wishful thinking
here :-). This last point may not be important unless the language packs get
really big.

Here is a quick idea (without a lot of thought, so it may need some work):

        langdb = LanguageRepository.new("myplugin", "myapp", "en-us")

This would perform a heuristic search for a matching language file. It would
search a set of directories for a matching language file. Perhaps these
directories (in this order):

        - The plugin's directory
        - The "language" subdirectory of the plugin
        - The directory of a plugin named "Language"
        - The base FreeRIDE directory

Maybe FreeRIDE should have a settable "language path", like Ruby's load
path. Anyway, in each of these directories, it would try to open files with
the following names:

        - "myplugin_myapp_en-us"
        - "myapp_en-us"
        - "en-us/myplugin_myapp"
        - "en-us/myapp"

And, finally, for each filename it would try a series of standard
extensions:

        - "xml"
        - "po"
        - "gdb"

This means that in the plugin code (or in generic FreeRIDE code) you don't
have to hardcode a filename for a language db, just specify the desired
attributes of the language db and let the system search for the appropriate
file.

At a higher level, a FreeRIDE plugin should have its own language db (which
you did mention), but it should be able to act as an *extension* of the
FreeRIDE's global language db. So when a plugin gets a translated string
like this:

        L?"FILE_NOT_FOUND"

If first looks in the plugin's language db and if its not found there, then
it looks in the global FreeRIDE language db.

A flexible way to do this would be to create a separate class for creating a
composite language db from one or more language dbs. For example:

        # get the global freeride language db
        GL = @plugin["/system/ui/language_db"]

        # create the local plugin language db
        L = LanguageRepository.new("myplugin", "myapp", "en-us")

        # create the composite language db that my plugin
        # will actually use.
        CL = LanguageRepositoryConposite.new
        CL.add(GL)
        CL.add(L)

        # use the composite language db
        puts CL?"PRESS_ANY_KEY"

So, in the last statement above, "PRESS_ANY_KEY" would get translated from
the plugin's language db unless that key did not exist, in which case it
would be translated from the global FreeRIDE language db.

In reality, I would expect the plugin loader to automatically create the
composite language db for the plugin based on information specified in the
plugin's XML file, and store a reference to it at a known location on the
databus. The plugin would retrieve and use it something like this:

        L = @plugin["language/db"].data
        puts L?"PRESS_ANY_KEY"

In addition, most of the FreeRIDE GUI framework would do automatic
translations of user-viewable text that is stored in the databus and used to
create visible UI elements. For example, the Save command (as implemented in
AppCommands.rb) defines the string "&Save" that is used to create menu-item
and toolbar-button names whenever the Save command use used in a menu or
toolbar.

The menu and toolbar rendering would automatically translate this name
(using the global FreeRIDE language db) before displaying the menu or
toolbar. When this is finally implemented, this string should probably be
changed from "&Save" to something like "CMD_SAVE".

Since a plugin can add new items to a menu, it must add language
translations for its new menu items (and any other global UI text) to the
global FreeRIDE language db. This means that the global FreeRIDE language db
should be a composite language db, and the plugin's XML file can specify
additions to the global language db (the plugin manager would, once again,
handle all the details automatically).

Comments?

Curt


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of
> Horacio Lopez
> Sent: Tuesday, July 30, 2002 3:15 PM
> To: address@hidden
> Subject: RE: [FR-devel] [Foxgui-users]Very alpha version of FR debugger
> inCVS
>
>
> >
> > Curt
> > I'd still like to get a rudimentary "gettext" like facility in there for
> > internationalization, and we could use a help facility with minimal
> > documentation.
> >
>
> I got my hands on it...
> I will release it ASAP !!
>
> I am designing it so that you can use different
> text databases, and you don't have to deal
> with the gettext innards yourself.
>
>
> I'm still trying to decide what gettext module is
> the best for our purposes.
> For now I will try to provide something
> as rubiesque as I can.
>
> # Opening a language resource database:
> # -------------------------------------
> langdb = LanguageRepository.new("gettext","./langdb/freeride.po")
>
> langdb = LanguageRepository.new("xml", "./langdb/freeride.xml")
>
> langdb = LanguageRepository.new("dbi", "mysql:freeride" )
>
> langdb = LanguageRepository.new("gdb","./langdb/freeride.gdb")
>
> # Once you open a language resource database
> # you can retrieve a language set for your application
> # In the case of file-based systems like gettext .pos
> # -----------------------------------------------------
> L = langdb.Language("myapp")
> L.select("en-us");
> puts L?"PRESS_ANY_KEY"
>
> # you also could do things like:
> mybutton.setlabel( L?"DELETE" )
>
> # search text in the language database using
> # euc-kr korean encoding, but retrieve text from
> # the database as utf-8 strings
> L.SetEncodingInput("euc-kr")
> L.SetEncodingOutput("utf-8")
>
> # Inserting a new language string
>
> L.store("es-sp", "HELLO", "Hola" )
> L.commit
>
>
> # moving strings from one database to another
> gt_len_db = LanguageRepository.new("gettext","./langdb/freeride_en.po")
> gt_lsp_db = LanguageRepository.new("gettext","./langdb/freeride_sp.po")
>
> xml_outdb = LanguageRepository.new("xml","./langdb/freeride.xml")
>
> E = gt_len_db.Language("myapp")
> S = gt_lsp_db.Language("myapp")
>
> S.SetCharsetInput("iso-8859-1")
> S.SetCharsetOutput("iso-8859-1")
>
> E.SetCharsetInput("us-ascii")
> E.SetCharsetOutput("us-ascii")
>
> O = xml_outb.Language("myapp")
> O.SetCharset("iso-8859-1","iso-8859-1")
> O << "es-sp"
>
> O.store( E?"TEXT_PRESS_ANY_KEY" )
> O.store( E?"BUTTON_HELP" )
> O.store( E?"BUTTON_DELETE" )
> O.store( E?"MENUOPTION_FILE" )
> O.store( E?"MENUOPTION_EXIT" )
>
> O.select("es-sp")
> O.store( S?"TEXT_PRESS_ANY_KEY" )
> O.store( S?"BUTTON_HELP" )
> O.store( S?"BUTTON_DELETE" )
> O.store( S?"MENUOPTION_FILE" )
> O.store( S?"MENUOPTION_EXIT" )
>
> O.commit
>
> # Now the text is retrieved form the XML database
> puts O?"TEXT_PRESS_ANY_KEY"
>
> # You don't know the hash key, but you know
> # how to spell it in your language:
> O << "en-us"
> O >> "es-sp"
> # output in spanish -->  Pulse una tecla
> puts O("Press any key")
>
> # Translating a text file
> f = File.open("mykeys.txt")
> f.each do |line|
>   print O(line)
> end
> f.close
>
>
> -----------------------------------------------
>
> FreeBASE should have its own database, the same way
> separate plug-ins should have separate ones too.
>
> Work ahead:
> * define standards for database storage
>   + DTD for XML databases
>   + SQL schema for rdbms based databases
>
> * stabilize api
>
>
> maybe you have better ideas, or suggest a different syntax
> that's what's in the works right now.
>
> after I got this, I will create a visual plug-in
> that can:
>
> * show the contents of a language repository
>
> * edit its contents
>
> * extract strings in the form L?"text" from
>   ruby source code, and generate a language database
>   from it.
>
> Alternatively, we could use the language repositories
> for storage of help files too
>
> Quirks ? Misconceptions ?  Awful code ?
> Please let me know what you don't like
> it's still early enough to redesign.
>
> I know I've been slow , damn too slow
> code and documentation SOON, SOON, SOON
>
> cheers
>
> vruz
>
>
>
> _______________________________________________
> Freeride-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/freeride-devel
>