Case sensitivity and LanguageHandler

Continuing the discussion from Language handler question:
if I have the string “vertical” and also the string “Vertical” in my script’s UI stuff can LanguageHandler tell them apart?

Why not include them both ??
“Just in case…”

everything between quotes need to be identical , including case and leading or trailing whitespace…

I have taken to using separate lines and split out punctuation as well…

      prompts = [
        TRANSL8['Circle Radius'] + ':',
        TRANSL8['Segments'] + ':',
        TRANSL8['Waves'] + ':',
        TRANSL8['Wave Height'] + ':',
        TRANSL8['keep Circle'] + ':',
        TRANSL8['keep Cylinder'] + ':',
        TRANSL8['Explode All'] + ':']

the string files become easier to proof read…

"Circle Radius"="Rayon du Cercle";
"Wave Height"="Hauteur d'Onde";
"keep Circle"="Garder Cercle";
"keep Cylinder"="Garder Cylindre";
"Explode All"="Tout Eclater";


Let me try to get the most important theme across to you about the LanguageHandler class.

The LanguageHandler class is:

  • dumb, ie, it has no “smarts” nor “intelligence”
  • it is a simple “lookup” function
    • it look’s up a key being an English string in a Ruby Hash, and returns the string value for that key.
    • the string value is the local language that YOU manually translated when you created all the various .strings files for your extension.
  • the LanguageHandler class does NOT translate English “on-the-fly” (because most translation engines on the web, forbid their use this way.)
  • the LanguageHandler class uses twice the amount of memory just loading your translated strings into a Ruby hash does.

For these reasons, I do not use the LanguageHandler class at all. I just write Ruby files (that are part of the extension’s files,) that define a language hash (within my extension module) that uses short symbol keys.

thank you for the quick answer.

You may have misunderstood my question. I just wanted to know if the LanguageHandler look up function was case sensitive. The word ‘vertical’ is translated to ‘senkrecht’ in my German language file and the word ‘Vertical’ with a capital first letter is translated to ‘senkrecht’ because Germans are fussy about capitalisation whereas we Irish use artistic licence. I just wondered if the capital letter would trip LanguageHandler up.

I did not realise that LanguageHandler was memory greedy. Do you recommend I drop LanguageHandler and just create a set of language Hashes to do the translation?

I did but was worried it just might confuse LanguageHandler .

thank you for the quick response. LanguageHandler is case sensitive then. I know not to worry about that in terms of errors occurring in my scripts.

It has two copies of every string in it’s internal hash.

But you can eliminate this, by only temporarily creating a LanguageHandler object, extracting the locale string translations to some internal references, and then disposing of the LanguageHandler object.

For example, during startup, build up the arrays of your inputbox prompts, defaults, options, etc., and assign references to some persistent object (local constants, or module variables, etc.)

require 'langhandler.rb'
@lang = LanguageHandler::new("my_plugin.strings")
# Load up inputbox arrays etc.
# other message hashes etc.
# and menu commands names
# dispose of the LangHandler object
@lang.strings.clear  # call the Hash#clear method.
@lang = nil          # mark it for garbage collection

Do whatever you are comfortable with.

I think the Ruby’s compiled parser is faster at parsing a ruby script with just a hash definition, then LanguageHandler’s Ruby parser parsing “strings” files.

I find LanguageHandler’s implementation awkward and clunky.

thank you for this, as always, very interesting and useful summary. I agree that LanguageHandler’s implementation is very awkward and clunky and has many undocumented foibles. It can’t handle LanguageHandlerobject["some string #{code_or_variable} some more string "] for instance. You have to write it as LanguageHandlerobject[“some string”] + code_or_variable.to_s + LanguageHandlerobject["some more string "] which makes the code look even worse than it already does.