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

[Horacio Lopez]

> 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).

ok, as Laurent and Curt suggested I am focusing on XML right now.

Let me say XML supports utf-8 as one of its possible encodings
and it supports most of the human languages in the world, 
but there may be some character sets not supported by utf-8.
(a non-unicode large japanese character set comes to mind)

That's why I thought of the alternative storage devices for
repositories.
For now, XML will do just fine, but expect problems with
it when working with multibyte japanese text.
(and possibly others)

Curt, I agree with all your comments, and I am going to make
the necesary changes.

I hope my english is clear enough to answer Hal's questions too,
sometimes I know my english has some quirks, and may not be
as clear as desirable.
(if my explanations are not enough, please guys help me)

Hal... the L?"TEXT_PRESS_ANY_KEY" syntax means
you are retrieving a string value from a language db
being "TEXT_PRESS_ANY_KEY" the key in that
key-value pair table.

Some advantages:

* it's shorter, readable and easier to write than
  equivalents in other languages...
  an example of achieving the same thing in Java:
  http://java.sun.com/docs/books/tutorial/i18n/intro/after.html
  it's much more verbose.

* This simple syntax allows us to easily extract all the
  occurrences of internationalizable text that appears
  in the source code.
  That way you can write an app without even caring
  of creating your language databases, you can do it
  later by extracting all the strings and translating
  them as needed. (with a future visual translation plugin !)

I don't know if it looks weird for ruby coders,
you are way more experienced in Ruby than I am,
so any suggestions will be taken into account.


----

Now.... some additional thoughts.

One of the sources of documentation on I18N I have taken
into account was the Java documentation.
http://java.sun.com/docs/books/tutorial/i18n/intro/after.html

In Java, they use "resource bundles" instead of 
"language repositories".
A language resource, from their point of view, is
just one of the many types of resources
(other resource types could be bitmaps, text files, etc)

In Win32, for example any EXE or DLL can be a resource 
repository too. (including language tables)

I am thinking of expanding the concept we had.

What happens if you have an icon with a STOP
sign ?
What happens with Help files in different languages ?

I think eventually we should end up extending
the concept of the repositories to admit
data types other than language hashes.

not right now, but eventually..... just a thought


comments, suggestions, advice ?
anything will do :-)

cheers


vruz