Support of Language translation - LibTraductor.rb
-
When I designed the script bezierspline.rbI indeed bumped into the problem of language translation, both as a script programmer and as a script user. I made some research on what existed in terms of practices and tools and found very little. In general, scripts are written in a single language (English usually), and then the script is converted by someone into other languages, by modifying strings in the code and renaming the script file. For instance you have bezier.rband fr_bezier.rbon the Crai Ruby Depot.
There are a few issues with this approach:
- Having several versions of the file makes it more difficult to keep potential upgrades and bug fixing in sync.
- Some errors can be made when translating strings embedded in the source code. You can forget to translate some, or accidentally translate strings that you should not.
So I came up with this small library LibTraductor.rband a set of practices to rationalize a little bit the coding and the language translation management of Sketchup scripts.
The principle is to provide a way to define and use strings that carry their own translated version.
Mystring = "Hi |EN| Welcome |DE| Wilkommen |FR| Bienvenue"
The macro provides utility functions to support:
- The definition and usage of multi-language strings, including substitution patterns with %1, …, %9
- Mass assignment of string constants to variables
- The designing of dialog boxes, with language translation and built-in validation
- A few utilities on hash arrays (marshaling, un-marshaling, pretty print)
Usage: just drop the macro file LibTraductor.rbin the Plugins folder of Sketchup, and in your script just insert a statement:
require "LibTraductor.rb".Test utility: I published a test macro LibTraductor_test.rbto show some examples. It adds 4 menu items in the Plugins menu of Sketchup.
Compatibility: the macro should work with Sketchup v5 and v6 (Pro and free versions, English and French). I tested it on Windows XP and Vista. I don't know however if it works on Mac
Programming manual of the Traductor library:
http://www.sketchucation.com/forums/scf/sas/Ruby/Tutorial%20Traductor%20-%20v1.pdfTest utility for LibTraductor:
http://www.sketchucation.com/forums/scf/sas/Ruby/LibTraductor_Test.rbScript library to drop in Sketchup Plugins folder:
http://www.sketchucation.com/forums/scf/sas/Ruby/LibTraductor.rb -
Why not using LangHandler? In this case the translations only would need people translating from English (keys) to the desired language (values) in a separate text file. With your script you need to edit the strings in all including scripts to support a new language, with LangHandler you only have to provide a new text file and the person translating for your script
- does not need to edit the code
- can't inspect your code
This also works fine for later string (UI) modifications also if the script is scrambled.
-> divide et impare
azuby
-
Several remarks:
-
you are definitely right. It is more elegant with a separate file, so that you can proceed with the translation without touching anything in the code itself
-
the Sketchup Ruby documentation is really poor . I did not know LangHandler, and furthermore, that it was provided in the standard tool librairies of Sketchup. The script itself is not commented. I am sure many of us would appreciate if the Sketchup team could improve the doc.
-
I will indeed adapt LibTraductor to manage strings in external files, in order to keep the additional functions I wrote on dialog boxes.
Thanks a lot for signaling this to me.
By the way, I never found a Sketchup macro that had a separate 'string' file, but instead I found many that were published as several versions of the same macro translated within the code (like bezier.rband fr_bezier.rb, also written by the same @Last Software). Is this because Sketchup Ruby programmers don't really bother, or because nobody knows really about LangHandler?
-
-
Bah moi j'ai jamais vraiment réussi à m'en servir...
(Didn't really had luck with the use of this...) -
I've used LanguageHandler in some of my extensions. The bad thing with it are the changes Google makes from version to version. And they do not tell about.
azuby
-
It's easy anyway to replicate LangHandler with your own version you control (and anyway a GetString method that takes a default in case the string is not found).
My observations were that it's seems that the community of Ruby 'scripters' prefer to avoid proliferation of files and deliver extensions with one or very few files.
Advertisement