Internationalization of Scripts

Kidd wrote here:

/54/56/201814/1.html#post1615633

>> Absolutely. Though I'd consider storing the text in notecards, a separate one for each language, so that you don't have to have all four languages in memory.

Hmm. Kidd. You still there?

I'm mulling over the notecard idea that you mentioned.

My translation engine script -- the one that I loaded all the translations for terms into to stop the other scripts from blowing up over lack of memory -- is itself choking now. Yep, I was storing all the translated terms right in the script such as:

list CfgCard1 = ["Config card not found", "Carte de configuration pas trouve", "Konfiguration Karte nicht gefunden", "Carta di configurazione no si trova"];

There are 40 such lists defined in the script altogether, LOL!

So this means that if I want eventually to add Spanish, for instance, or if some French people complain (you can always count on the French, grin) that I played loose and free by shortening terms too much in French and I need to add more words back in to the French expressions -- well, I'm going to be stuffed in short order. No room to grow.

So let's say I move all these lists to a notecard. If the language currently desired is German, let's say, then I'm after item [2] in the list (lists starting their count at 0.)

It already helps me in that I've freed up compile-time memory in the script. But couplo questions before I rewrite this yet again.


Q 1. Say I read the above sample Config Card list in from a notecard and call it tmpconfiglist. I then grab the specific item in the list I'm after. So tmpconfig = item2 in that list. If I then go tmpconfiglist = [], will that throw the list away, and free up runtime memory for sure?

Q 2. If I make the notecard no modify (therefore read-only), the script for sure can still access it, right? I mean, I could live with having to make it modify, but as I'm going to be relying on a list structure properly formatted in the notecard, probably best if I spare people the danger of mucking it up.

Q 3. Finally, a brave and daring question. In the above Config Card list example, in the French, I was forced in the script to spell the world "trouve" ("found" wrongly. The correct spelling is instead "trouvé" with the accent on the end. Try any non-American English usage character in a script, and it spits in your face pa-tooey. Real PITA when Americans are now a minority nationality on SL. So that's why I have to spell all kinds of words wrongly in all kinds of languages when typing them directly into a script. IF instead I am reading them in from a notecard, and always just referring to them as variables in the script, could I use accents? Variables are used for say and whisper msgs to users. A couple are used for menu headings. Some are used for menu buttons. I have a feeling I might be okay on the say msgs; might be asking for trouble with the menu stuff.

Second, separate query within the same general topic.


What if in a notecard editable by end users (where they set their choices and settings) I had this:

1=15
2=loud bang

and below those lines had help such as:

#1 Base Position / Position de basse / Niedrige Position / Posizione bassa
#2 Sound / Son / Ton / Audio

In such a scenario, there's just one config card, with the #help lines explaining what the numbered lines are for.


Currently, I think I have it implemented in a real hardcore way.

Based on language, a script picks the correct starting parameter to look for from a list like this:

list BasePosParamList = ["Base Position=", "Position de basse=", "Niedrige Position=", "Posizione bassa="];

then also based on language, goes to one of four notecards (.config_English, .config_francais, .config_Deutsch, .config_italiano) and looks for the translated parameter in the notecard for that language.

It's no work to just keep it the hardcore way I have it, if you think that's more user friendly. This "hardcore" way has the benefit of allowing people to only have to see the language of their choice, and not have to wade through foreign (to them) language words. For instance, in the simplified example, it would be alright for us English speakers, as that example always places English first in the list of explanations.

#1 Base Position / Position de basse / Niedrige Position / Posizione bassa


But just to walk an inch or so in the other guy's shoes, picture hunting for the English term third in the explanation list after German and French. You might get bewildered.

#1 Niedrige Position / Position de basse / Base Position / Posizione bassa

Maybe. Dunno.

The simplified version is a bit less maintenance intensive going forward, and certainly less memory intensive on the scripties. But the hardcore version as I already have it might be more user-friendly.

Anyhoo, opinions anyone?

I prefer one notecard per language. And each message has an id. Easy to add more languages that way, and organize the messages.

So at the startup, the script selects the correct notecard. And if needed, can read all the messages into memory (or leave them in the notecard and refer to them by line number later).

So in your script you might have to print message id 25 someplace, then just read message id 25 (or line 25 if you do it that way) from the preslected proper notecard.

Also on the Unicode/UTF characters, I was hoping they fixed that by now. If not, you can represent the unicode in the notecard, then when you read it, call llUnescapUrl to translate it back to an printable international character before printing it.

Some escape codes can be found at:
http://www.nlm.nih.gov/databases/dtd/medline_character_database.html