Localization & Internationalization best practices with 3.0 ruleset layering

[Moon Wizard]

Before we do any ruleset sales through our store, we work with the publisher to get their permission to offer the ruleset for sale along with the core rulebooks for that system. As part of that negotiation, we ask for copies of the rulebooks in order to get them imported. So, yes, if we do an official ruleset, we'll get the developer an English version (and other versions if we can get them and the developer wants to do language packs).

There are so many "small" features that end up being much larger than they seem once all the pieces are factored in. These string assets for translations are a prime example.

I agree with the graphics lettered graphics being something that needs to be handled by the translation extensions. Either that, or I need to change up the whole sidebar button approach.

Cheers,
JPG

[Blacky]

OK, the "you" I was referring to wasn't you (Blacky) particularly, it was a generic you as in "hi, you cats, what's happening".

No problem, I also do that a lot (well did, since I was also misunderstood a lot with that phrasing)

[Blacky]

Before we do any ruleset sales through our store, we work with the publisher to get their permission to offer the ruleset for sale along with the core rulebooks for that system. As part of that negotiation, we ask for copies of the rulebooks in order to get them imported. So, yes, if we do an official ruleset, we'll get the developer an English version (and other versions if we can get them and the developer wants to do language packs).

Ok good to know. But that doesn't cover community resources.

Maybe the guidelines could suggest that most resources be natively written for English, if only because there's a larger audience and more importantly (for community ruleset where the number of use isn't important) because there's more people to help with the coding, maybe maintain the ruleset if the author abandons it, and so on. But as a suggestion, of course in some cases that would be impossible, in other the author simply won't do it.

There are so many "small" features that end up being much larger than they seem once all the pieces are factored in. These string assets for translations are a prime example.

Would a xml lang attribute for root (or something similar) had any side effects?

By the way any plan to put the launcher in strings as well? (we'll know demonstrate how to make a developer hang himself in front of his computer ^^).

I agree with the graphics lettered graphics being something that needs to be handled by the translation extensions. Either that, or I need to change up the whole sidebar button approach.

It's not an issue to localize these. Although it would help non-graphic people and beginners to have the source file, maybe a layered tiff for example (very simple to export in Photoshop, and compatible with any decent software whereas I'm not that sure about PSD), to work with if need be.

I just wanted to point that out. You could do it in code (real pure text, and rotate and place as needed) but personally I wouldn't put this on top of other things (like documentation with community comments, token stacking, map text labels and such) on the todo list.

[martel]

For me, ALL string must be in an external file... as file i18n in java. on file per langage. easy to translate the file original eglish in other langage.

filename : Core_English_v3.0.properties
core.base.strong = strong
core.attribut.reflex = reflex

filename : Core_French_v3.0.properties
core.base.strong = force
core.attribut.reflex = réflexe

for Ruleset Extension or Module campagne
filename : NameIdModule_English_v1.0.properties
filename : NameIdModule_French_v1.0.properties

it is very very powerfull :-)

[Blacky]

I'm not sure that what you have in mind, but currently with CoreRPG all text (apart from graphics, and the launcher) is in a strings directory, with a few XML string files. Including the basic FG strings, which is a big improvement compared to 2.x.

It looks like this:

<root>
    <!-- General -->
    <string name="visibilityon">Visible to All</string>
    <string name="visibilityoff">Visible to GM</string>
    <string name="list_menu_createitem">Create Item</string>
    <string name="list_menu_deleteitem">Delete Item</string>
    <string name="list_menu_deleteconfirm">Confirm Delete</string>

And so on.

Of course XML is quite verbose, but apart from that it's quite good. Not as polished as po/mo for example, but easier to use for the general public. And even without good coding skills, the name attribute means one can search for it in the ruleset in 2 or 3 clicks, and have some idea of the context.

And it uses the same basic layering capability as the rest of the ruleset/extension code. If someone would post a basic layer documented example, even a non-geek could learn how to translate under an hour I guess (and that's for a really non-non-non geek).

It also by design handle evolution, a new string for a new CoreRPG tool for example will not break anything, we'll just get that new text in English until it was added to the localization addon.

But, it's not “external”. One has to unzip the pak/mod/ext yeah.

The only caveat I see with this, is that there's currently no published source or diff. So to maintain something, one has to keep a before-each-update backup of the pak/ext and manually launch a diff to see if anything has changed, and what exactly. It is somewhat time consuming, especially while keeping with alpha (but alpha isn't a production release by definition, so I guess maintainers can stick to the live channel, although hot fix can be stealthy ).

[Blacky]

One question about making language packs as extension: is there a way to control the order of the extensions loading (or, to control which one take precedence over another)?

Because as far as I can see it, Extensions are the last refuge for home-brewed rules and table habits. This is especially an issue in the localization arena, because a bigger portion of the players have their own taxonomy (because the official localization is terrible, let's say Warhammer for example; or because players have been using their own table localization for months or years before an official got, let's say Eclipse Phase but their are countless others).

[Moon Wizard]

It shouldn't be an issue for localization packs for the most part, since they are just overriding string assets for the most part. It could be a problem with the graphic replacements, and themes.

There is a load order tag for extensions. You could just set this high (i.e. 100) to ensure that the language extensions are loaded last.

Regards,
JPG

[Blacky]

Last loaded means the lowest priority? It wouldn't override things?

I just wanted to be sure to leave some room for the house or home-brewed rules and usages.

[Griogre]

Last loaded, in this case means last loaded. It's the last thing to happen before the ruleset loads so it would have the chance to override anything that has been loaded before it in the load order from ruleset, ruleset imports, to other extensions. In a sense it would be the highest priority, but what I think JPG was saying was while this would be desired/fine for translation strings, that's not necessarily true for art or other ruleset assets.

If you are worried about homebrew or other assets you should limit your translation extension to only things needed for localization.

[Trenloe]

One question about making language packs as extension: is there a way to control the order of the extensions loading (or, to control which one take precedence over another)?

Answered in post #8 with link to documentation!

https://www.fantasygrounds.com/forum...l=1#post166702