Localization & Internationalization best practices with 3.0 ruleset layering

[Blacky]

What would be the best practices for localization and internationalization with the new 3.0 ruleset layering (cascading) capability?

What would work best for everyone, especially the end user, even if maintenance is spotty?

Let's take a practical example (just an example mind you): let's say someone wants to make an Eclipse Phase ruleset, and that someone wants to play Eclipse Phase in French.

Would it best be done purely in ruleset? If so, it could be CoreRPG→CoreRPG French→Eclipse Phase→Eclipse Phase French? This would allow any ruleset translation to pile up on already existing translation for common (Core) strings. Or purely CoreRPG→Eclipse Phase→Eclipse Phase French? Or something else?

Would it be best done as extensions?

And what about features or rule extension (for example the D&Dish Town&Shop extension for Core)?

And what about modules in general (with the exception of story or background modules, which would of course need to be completely rewritten)?

[Moon Wizard]

Well, considering that the internationalization is fairly new, I think we'll be figuring this out as we go.

The current internationalization is built purely on the concept of string assets. This means that they can only be defined in rulesets or extensions. I would suggest that string asset changes be made as extensions at this point.

Modules are purely data to FG, so not affected by string assets at all.

Regards,
JPG

[damned]

i would think you could/would/should make your language extension last - keep all the language changes in one location?

so maybe: corerpg -> new ruleset -> language extension
or even: corerpg -> new ruleset extension -> language extension

[Blacky]

Well, considering that the internationalization is fairly new, I think we'll be figuring this out as we go.

Yup I know, which I why I brought it up. Having some talk about it, and some guidelines and best practices, might help other people in the future. And since there's no central knowledge base to put this on (wink wink), then the forum is the next choice to have this.

The main global issue is, is there internationalization? Are there guidelines (or will there be in the future), customs, taxonomies, in short some kind of organization for this type of things? Or is it a free-for-all melee?

It has consequences either way.

The current internationalization is built purely on the concept of string assets. This means that they can only be defined in rulesets or extensions. I would suggest that string asset changes be made as extensions at this point.

I would suggest that strings are at least in their current form, purely a translation tool. There's a difference, sometime a big one, between translation and localization. Look at the calendar for example. Translating for example in French means: Monday→Lundi. Easy enough. Localizing means adapting it to the locale. For example Thanksgiving is a major holiday in the contemporary US. It's on a different date for Canada and the very few others place following it like Liberia or the Netherlands. It's unheard from in other countries, including English speaking UK or Australia and such.

Localization include all these little things that are different locale from locale, country from country. It's mainly translation yes, but not only. It's date format, number formating, customs and habits, alphabet collating, and so many more.

From a technical point of view, I'm not sure the current strings are enough, but I may be wrong.

Modules are purely data to FG, so not affected by string assets at all.

What would be best practices for those then?

Let's say I do a generic tokens module, for example some king of cartographic set with words on the images (to circumvent the absence of type on maps in FG) and I integrate a Library page with it for explanations and license. Localizing this to another language means updating some of the graphics, and the library page. Do I do another module? Do I integrate these in the base updated module?

[Blacky]

i would think you could/would/should make your language extension last - keep all the language changes in one location?
so maybe: corerpg -> new ruleset -> language extension
or even: corerpg -> new ruleset extension -> language extension

Could be. But that would mean people have to reinvent the wheel each time, and the end user has no stable basis. Look at the base FG functions, the radial tools for example. With a few good idea, their best translation could be written, and maintained by the community. But the final ruleset localizator would have to do this on his own in your example. And if changes are necessary, or mistakes have to be corrected, he has to do so each time, and again alone.

On the other hand, if a central repository is done, or if the ruleset translation ground itself on translations of layered ruleset, it means both organization (with the tools to do so) and communication are necessary.

I'm not pushing anything in either way. I just want this to be well thought, myself doing the Devil's advocate if needs be; and I want to know if there's an official (meaning SmiteWorks & community pillars) position or vision about this.

I know that for most people, Fantasy Grounds is only as good as the ruleset in the table language, for their current game and way of gaming. And only if they know about it.

I also know that for most, it was until know a free for all. I remember a few weeks ago someone posted a new Dark Heresy English ruleset. For at least a year there was another one, with much richer data and graphics (I don't know about stability and pure code features), only it was in French. Maybe the English ruleset coder didn't care either way. But maybe he wasted hundreds of hours reinventing the wheel for nothing.

Since 3.0 and the new CoreRPG was the perfect time to redo documentation, community tools, and such and without addressing the rest of it (well, lack of) I wanted to know if something was to be done in the i18n arena. And if there was code derived best practices I was not aware (could be anything, like too many ruleset layering is bad for performance or whatever).

[dulux-oz]

OK, my $0.02 worth, being based on a similar situation I once had to cater for for a Web Project I was the Project Manager for:

Language Paks should be the LAST thing applied to the "Ruleset Stack". This means that those using the base language never have to worry about Language Paks, software forks, etc. Yeap, its a bummer for those not using the base language, but that's just how its got to be.

Those using another language will need to use one OR MORE Language Paks, depending upon how "deep" their particular Ruleset Stack goes. Each Ruleset would have a relevant Language Pak in whatever language was appropriate, with "Cascading Language Paks" applied last in the Ruleset Stack in the same way that "Cascading Rulesets" are applied.

My STRONG suggestion is that Language Paks are applied as Ruleset Extensions.

OK, let's look at some examples:

1) CoreRPG in English
Result: CoreRPG Ruleset

2) CoreRPG in French
Result: CoreRPG Ruleset => CoreRPG French Language Pak (Extension)

3) 3.5DnD in English
Result: CoreRPG Ruleset => 3.5DnD Ruleset

4) 3.5DnD in German
Result: CoreRPG Ruleset => 3.5DnD Ruleset => CoreRPG German Language Pak (Extension) => 3.5DnD German Language Pak (Extension)

5) HomeGrownRPG (based on 3.5 DnD) in English
Result: CoreRPG Ruleset => 3.5DnD Ruleset => HomeGrownRPG Ruleset

6) HomeGrownRPG (based on 3.5 DnD) in Spanish
Result: CoreRPG Ruleset => 3.5DnD Ruleset => HomeGrownRPG Ruleset => CoreRPG Spanish Language Pak (Extension) => 3.5DnD Spanish Language Pak (Extension) => HomeGrownRPG Spanish Language Pak (Extension)

Hope this helps clarify and develop our group "Standard".

Cheers

[Blacky]

Base language everywhere, there's one big issue. There's already a lot of natively non English content. From the top of my head I can think of at least fifteen French ruleset for example. Some are adapted version of existing English ruleset, some aren't, and some are for purely French rpg that doesn't exist in English.

And to add one little twist, for example I'm currently working with bzjeurd on a ruleset for a French game that has an English translation in its distant future. How would you handle that?

As for language packs as extensions, I wonder, there's currently no cascading within extension or is there?

[Trenloe]

As for language packs as extensions, I wonder, there's currently no cascading within extension or is there?

Yep, there is - anything in a later ordered extension overwrites the same information/data from earlier loaded extensions. Use the <loadorder> tag to control the order extensions load.

<loadorder> is mentioned in the documentation on the extension.xml file: https://www.fantasygrounds.com/refdoc/properties.xcp

[dulux-oz]

Well, I hate to say it, but that's the thing when a new "Standard" is proposed - there is often a load of work that needs to be done to bring older, non-Standard "stuff" up to quality.

In other words, if we as a community go with the Language Pak Standard I've proposed (or something similar) than those Rulesets not written in the Base Language (with a Language Pak) won't be "Standard" ie won't be compliant - they'll still work, obviously, but they will be "Non-Standard".

We're already doing this - those older Rulesets that don't comply with the new CoreRPG Cascading Standard are/will be re-written (eventually, I hope) to match the new Standard - we'll just have to do this with the Language Pak Standard (if its adopted) as well.

Look, I know its a sh!tty idea for all the non-English speaking users of FG (assuming we decide on English as the Base Language) but its going to be sh!tty for ANYONE who doesn't speak the Base Language - whatever that Base Language eventually ends up being - and considering that English is the new Linga-Franca for the world (or at least the Western World) AND the fact that FG is developed by and owned by English speakers (well, Americans, at any rate ) then I think English will have to be the Base Language - then we're stuck with it.

I'm sorry, but that's the way its going to have to be.

Unless we let everyone do their own thing and thus end up with a complete spaghetti pile of "stuff" that WILL end up being incredibly hard to maintain and build upon.

I know which I'd prefer!

Again, just my $0.02 worth.

Cheers

[Moon Wizard]

I hadn't fully thought through the layering for translations, as I assumed that the translations would be done on the final layer.

The separate translation extensions for CoreRPG and the top layer ruleset are an interesting idea from a maintenance perspective, but not as great from an end user perspective. Have to click two extensions instead of one.

I could go either way, but then again, I only speak English.

JPG