LanguageHandler ?

Didier Bur

Hi,
I have translated numerous plugins to french, and Fredo has developed LibFredo6 to manage languages, thak2haka did something similar, and TIG as well with debabelizer.rb.

I was wondering why the LanguageHandler object has almost never been used by coders, along with a ".strings" file.
Is it buggy ? difficult to use ? What's your opinion ?

thomthom

I found it impractical.

If you have multiple classes or modules that needs to translate strings you need to make the LangHandler instance to them some way. Either by passing the instance to each class or module methods (which I find awkward), or use global variables (which I never ever use to ensure I never run into namespace conflicts.)
.GetString felt too verbal and long when you have many strings.

Like Fredo, TIG and thak2haka I made my own system:
A module named S wrapped inside my plugin's root namespace.
This module has a .load and a .tr method.
S.load loads the language file into a hash dictionary.
S.tr returns a translated string from the loaded dictionary if possible. If not match is found it returns the original string.

So my construction looks something like this:


module TT_Plugin
  module S
    def self.load(file(
      # ...
    end
    def self.tr(string)
      # ...
    end
  end

  def self.my_method
    # Assuming S.load has been called previously.
    puts S.tr('Hello World')
  end
end # module

S.tr('Hello World') is short and simple and available within my plugin's namespace.

It also allowed me to expand the language file format I used to fit my need - I also wanted to include translator names and contact info tinto tags I could extract and display in my plugin. I also wanted to have support for comments in the language files.

thomthom

This is the code I use in Vertex Tools. It is not plug and play as there are a couple of ties to Vertex Tools, but that is easily removed and I plan to port and clean up this into TT_Lib for use in my other plugins.

l10n.rb

fredo6

For me, same reasons as TIG's. The SU library is cumbersome and should be rewritten anyway.
The main issues I wanted to overcome were:
[list]
[]compatibility (make sure the program does not crash because of missing or incomplete translation)
[]support of 2-bytes languages.
[*]independency of strings (i.e. not used the english text as the key, because it could itself be subject to change)

I ended up with a transaltion from within the application, and a simple ascii encoding of all languages from their UTF codes.
Within the code, I used a simple notation (T6, based on symbolic keys).

Fredo

thomthom

@unknownuser said:

I ended up with a transaltion from within the application, and a simple ascii encoding of all languages from their UTF codes.
Within the code, I used a simple notation (T6, based on symbolic keys).

ASCII encoding from UTF (presumably UTF-8) codes? What do you mean by this? UTF-8 -> ASCII is incompatible.

@unknownuser said:

support of 2-bytes languages.

UTF-8 characters can be up to 4 byte. The Euro sign is for instance 3 bytes long.

Didier Bur

Thanks for sharing your translator thomthom, very interesting.
@Fredo: your 3 good points makes 3 good reasons not to use LanguageHandler

fredo6

@thomthom said:

@unknownuser said:

support of 2-bytes languages.

UTF-8 characters can be up to 4 byte. The Euro sign is for instance 3 bytes long.

Actually, I just store the code value in plain ascii (as a number), whatever number of bytes it is encoded on).
But I guess the Language handler may have the possibility to read UTF8-encoded string when running on Windows installation for Eastern languages.

Fredo

thomthom

My language handler does also address the first point Fredo mentions, it has error handling which ensures that any errors in the processing of strings does not interfere with the main program and falls back to returning the untranslated string. It's an important point I forgot to mention.

thomthom

@unknownuser said:

@thomthom said:

@unknownuser said:

support of 2-bytes languages.

UTF-8 characters can be up to 4 byte. The Euro sign is for instance 3 bytes long.

Actually, I just store the code value in plain ascii (as a number), whatever number of bytes it is encoded on).
But I guess the Language handler may have the possibility to read UTF8-encoded string when running on Windows installation for Eastern languages.

Fredo

I have the language files encoded in UTF-8 and make sure not to manipulate the strings in any destructive manner. (Fortunately one rarely need string manipulation in SketchUp.) My webdialogs also use UTF-8 encoding and are marked as such with appropriate meta tag. SketchUp is a Unicode app that deals with UTF-8 fine, so the strings can be sent directly to SU's UI.
But it is absolutely imperative that ALL language files are in UTF-8 as I found that mixing ASCII/ANSI with UTF-8 strings confused both SketchUp and webdialogs. As long as one is consistent then UTF-8 can be used all the way through, just be aware of SU's Ruby version treating every thing as a set of bytes.

Even languages like Chinese and Japanese works perfectly.

fredo6

Tom,

I just say that the strings are just flattened when writing to the lang file and encoded when reading.

Anyway, I wrote this package a while ago, when I was not sure about Ruby and SU API. I would probably do differently today, simpler, because many features are not really used (like the cascading language, allowing to see strings say in Portuguese first, then German, then English, if any of them is missing.

Fredo