[REL] Rodeggo - Translation resource 0.1

[Lordy]

Rodeggo is a resource to help you translate your gamemode, you just define the strings for each language at definitions.xml and then use them inside your resources.

The resource can be found here

0. Simplified using

- Add strings to 'definitions.xml' to each language with an identifyier (see the examples there and don't forget to set the resource right)

- Inside other resources use 'strings = exports.rodeggo.importStrings()'

- now you can use strings.identifyier and it returns the string in the client's language

- the client can change the language with '/setlang identifyier'

- you can change clients language with 'exports.rodeggo.setLanguage(identifyier)'

1. Description

- This resource is meant for gamemode managers for translation purposes. It makes it easy for example to have help files in multiple languages without needing to script them yourself.

- You can also also script GUI or whatever really to be multilingual

- It's client side only on purpose, the language differs between clients but the server shouldn't differentiate between players. Serverside outputChatBox outputs for every client, so you'd need to loop them etc.

- Clients can set their language with '/setlang LANGCODE', where langcode is defined in 'definitions.xml' as one of the mentioned languages

- Other resources need to add 'strings = exports.rodeggo:importStrings()' before using this. Then you can just address them with 'strings.STRINGID', where STRINGID is the identifyer at 'definitions.xml' '' tag.

2. Definitions

- All string definitions are at 'definitions.xml'

- In order to add a new language, all you need to do is add an ''

2.1 tag

- name: language identificator used in /setlang

- You don't have to translate every string you have at ENG, it just looks at ENG if it doesn't find the string at LANGCODE.

2.2 tag

- name: The identificator of the string, used in strings.IDENTIFICATOR

- resource: the resource the string belongs to. You can always import strings of another resource, but it doesn't make sense to import them all. So by default it exports the strings belonging to the caller resource. See 'exported functions' for further reference

- the value of the xml tag is the translated string

3. Exported functions and commands

- All functions/commands here are client side.

3.1 function 'table importStrings([string resourcename])'

- returns a table full of strings which belong to the resource. I added the resourcename argument because it's a waste of memory to load all strings that are in the definitions file into memory for all resources. So it only imports those which have the resource name in their tag.

3.2 function 'bool setLanguage(LANGCODE)'

- sets and saves the client's default language to LANGCODE

- LANGCODE is the language identifyier at 'definitions.xml'

3.3 command 'setlang LANGCODE'

- sets and saves the client's default language to LANGCODE

- LANGCODE is the language identifyier at 'definitions.xml'

4. Internal workings

- At the start of the resource the script loads the currently saved language from clientside xml and then loads all English strings into a table (well actually the first tag strings). If the language is not ENG, then it overloads all strings that are in the saved language definitions. So when a language doesn't have for example GUI_WELCOMEMESSAGE translation, it doesn't overwrite the ENG one and always returns the ENG one instead.

5. Report bugs at https://forum.multitheftauto.com/viewtopic.php?t=28241

Edited July 4, 2010 by Guest

[Xierra]

Well, something like that is really useful. Especially for Russian or Saudi servers which they want to have Russian & English.

This one's a good idea. But it will take 2x larger script to make 2 languages.

Don't worry, you're not wasting time making it, instead maybe you're developing?

[Lordy]

Well I'm taking my time thinking about this one.. Also, I think I have to consider the things stated in Multilingual MTA threadhttps://forum.multitheftauto.com/v ... 02&t=28215 .. Is this resource really worth the hassle?

[Gamesnert]

It may be worth the hassle for servers which prefer multilingualism. I'm sure there are plenty of those servers. The arguments stated in that topic mostly apply to MTA itself. In C++, it's much harder to make something multilingual than in Lua, and because the main menu contains mostly basic stuff most people can understand (or at least randomly click) it's really not worth it. But on indivudual servers it's easier to implement, and servers might prefer it.

Oh and if I may make a suggestion, make it something like this:

<lang name="English">
   <!-- possibility #1 -->
   <string id="HELLO_WORLD" text="Hello world"/>
 
   <!-- possibility #2 -->
   <string id="HELLO_WORLD">Hello world!</string>
</lang>

-- Possibility #1
outputChatBox(HELLO_WORLD)
 
-- Possibility #2
outputChatBox(language.HELLO_WORLD)

In this way you can make it as descriptive as you like, without having to waste a long line on a difficult export.

[Lordy]

umm I don't think I could make it like in your second snippet. There is no way of creating a shared variable over all resource iirc. I can't declare HELLO_WORLD in one resource and then use it in another. If one wants to use it, he has to declare it himself like

HELLO_WORLD = exports.translator:getString("HELLO_WORLD")
-- somewhere later
outputChatBox(HELLO_WORLD)

But I can think of no way to directly declare global variables for all resources without modifying the resources themselves.

Might do something like this though

<lang name="English">
<string id="HELLO_WORLD">Hello world!!!</string>
</lang>

--in translator
-- strings are stored in a table
-- strings[resourcename][stringid] = "STRING"
function importStrings(resourcename)
if not resourcename then 
       resourceName = getResourceName(sourceResource)
end
return strings[resourcename]
end
-- in some other resource
language = exports.translator:importStrings()
outputChatBox(language.HELLO_WORLD)

But I see no way past the exporting with a function part.

[Gamesnert]

Well, you could make a small plug-in script for it. Just a small script that gets all the translations of one resource and declares is. Besides, that's why I also included language.HELLO_WORLD in the example.

[Lordy]

0.1 released. Can be found here

EDIT: Can this be moved into Resources section?

[Towncivilian]

Thread moved.

[Orange]

What about making a OOP library for LUA?

The, it'd be like:

Rodeggo:HELLO_WORLD("pl") - HELLO_WORLD is the key, pl is the language. It should return "Witaj świecie" You also can make it openFrame, or using its engine ;P

[Lordy]

No. The idea of this resource was that client could choose his/her own language and then they would be translated, not that a scripter defines in which language the current string comes.

[Xierra]

Hmm, this could save some time making it.

Btw lordy, can you give me a little example of making it? I don't really understand how btw.

[Lordy]

Alright. There's the definitions.xml file in the resource

Inside that, there are two languages defined, ENG and EST

You can define something else (preferable keep ENG as the first, it's essential for the resource to work). Just duplicate the ENG part and change it for example to FIN. Now translate the strings. You can always add new strings aswell, but you need to make sure that the first (ENG) has all the strings listed. The others don't have to have. The resource="rodeggo" part means that the string is meant to be called from rodeggo resource. You have to change it to any other resource you are using (or use a bit different importing)

Now in a random resource, you need to define

myStringArray = exports.rodeggo:importStrings()

Then you can use them like

outputChatBox(myStringArray.SOMESTRINGID)

SOMESTRINGID is the string name in definitions.xml

And when you switch languages with "/setlang ENG", "/setlang FIN" then outputChatBox should output different strings.

If you want to access strings which don't belong to that resource, you need to do

myStringArray = exports.rodeggo:importStrings(resourcename)

resourcename is the same as in string tag resource="" in definitions.xml

You can check the source of the resource as well, there should be one commented out example.

[Orange]

I meant something else. For example, we make a "Rodeggo" class. Then, we make a function which initializes an instance of it:

local Language = Rodeggo:ImportPlayerStrings(source)

or, clientside:

local Language = Rodeggo:ImportStrings()

And maybe, if you want a specified language:

local Language = Rodeggo:ImportStringsByName("en") --we want a "en" language

Then, we can get a language string by:

outputChatBox(Language.HELLO_WORLD)

Or by using a function:

outputChatBox(Language:String("HELLO_WORLD"))

That may be nice ^^