Le Sunday, 5 Jan 2003, � 17:44 US/Central, Jos� L. Rodr�guez Illera a �crit :

I use another approach for getting the same results. All interface language
translations are stored in a field, each row a message or a label, and each
column a different language. This is easy to export or paste into a
spreadsheet, easy then for translators and easy to put back into the field.

Language to be used for the interface (not for contents: this will require a
different approach) is in a global, say "lengua". The following function
retreives the correct translated string:
As for me I've being using in my HyperCard stacks three different ways of dealing with such a problem:

1.- What I used to call the 'matricial approach' * is basically the one Jos� describes: either a) one line per language and one item per topic, or b) the other way around. Some times I find it easier to take the a) way: the names of languages are listed in a button. Then you just have to say:
global qlang
{put line (word 2 of the selectedline of button 'Language' of field 'buttonsLabels' into qlang} -- or fldLabels, or partLabels , for that matter
and then
{set label of btn bt to item bt of qlang} ** -- or fl or pt

2.- The card approach is perhaps more specifically hyperCardian: everithing common is in the background. When the interfacial difference deals only with language strings, a bg fld does perfectly the job and you can use all the fonts and styles you want, as you want; moreover, you can even switch to the shared mode for common storage. When there are behavioral differences from language to language cd btns permit separate handlers. Also a large part of the code can be repeated in each card with the dialog strings differences; this may be less elegant from the programmer's point-de-vue, but it is certainly faster for an old computer.

3.- The occasionnal do-as-you-can way is suitable when you need few matching equivalents in few and different circumstances, example
repeat with i = 1 to n
if string = word i of "p�re pare padre pai vater father otec" -- this string can also be a variable, of course
then return word 1 of "m�re mare madre m�e mutter mother matj -- or any other variable
end repeat
Note that this ends up being a particular case of approach 1.

I guess this method could certainly be very improved using the R-R facilites, which I am just beginning to learn. The custom property feature of R-R is also a huge extension of the contents-button system of HyperCard, but I must confess I still am not clever enough to use them properly.

Manuel

_________________

� I learnt from Jos� that this is called an 'array'. Jos� is been a great help for me a few months ago, when I was stumbling my first steps with R-R. He also deserved the single malt reward!

**this is much more conenient with R-R since you can still identify the object by the <name> while you localize the label, whereas HC had me to {set the name of object X to ...} and check {if the short name of....}

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to