Localization & Internationalization best practices with 3.0 ruleset layering

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)?

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

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

Quote:

---

Originally Posted by Moon Wizard

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.

Quote:

---

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.

Quote:

---

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?

Quote:

---

Originally Posted by 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

---

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).

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:

Quote:

---

1) CoreRPG in English
Result: CoreRPG Ruleset

---

Quote:

---

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

---

Quote:

---

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

---

Quote:

---

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

---

Quote:

---

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

---

Quote:

---

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

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?

Quote:

---

Originally Posted by Blacky

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

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 :p ) 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 :D

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

Quote:

---

Originally Posted by 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.

---

That's a possibility, but you didn't answer my examples: we're working (nearing beta) on a ruleset for a French game that should be localized and printed in English in the future (could be months, probably more like next year). How do we do this?

Or, what about a ruleset for a game that has no English version whatsoever.

Quote:

---

Originally Posted by Blacky

That's a possibility, but you didn't answer my examples: we're working (nearing beta) on a ruleset for a French game that should be localized and printed in English in the future (could be months, probably more like next year). How do we do this?

Or, what about a ruleset for a game that has no English version whatsoever.

---

So what are you suggesting?
Its a very good point that as FG grows up it will benefit from a more standardised approach to all things and this is one that would benefit from having standards.
But having standards will always disadvantage some - a quick and dirty fix or a fix that works for one person/group might not be allowed under a standards based approach. It might also completely disadvantage everyone whose native tongue is something other than english if the standards based approach is language goes in extension at end. Or maybe it has no effect - you could code your ruleset that extends CoreRPG with internationalised strings in French with support for a further language extension on top of that - be it to turkish, german, spanich or english.

OK, I thought the answer was pretty implicit, but I'll make it explicit:

If we as a community go with a Standard (any Standard) then to be considered Standard-Compliant a Ruleset needs to be written in the Base Language - if there is also one or more Language Paks for languages OTHER THAN the Base Language then that's fantastic.

So, to answer your exact question (assuming that the community adopts the Language Pak Standard and English as the Base Language) the Ruleset that Blacky and bzjeurd are nearing beta on will need to be written in English (hopefully with a French Language Pak - and maybe others) to be Standard-Compliant. If they release their Ruleset and its not in English than it WON'T BE Standard-Compliant!

It's as simply as that.

OK, so does that mean that they can't/shouldn't release their Ruleset?

Of course not!

What it does mean, however, is that until they do release it IN THE BASE LANGUAGE it won't be Standard-Compliant - so what does this mean? Nothing! Except that it may have a bearing on others using their Ruleset and basing their own variants on their Ruleset. Whether this is a problem or not is one that the community will have to judge.

So, if it were up to me and I was developing a new Ruleset (no matter what language I was working in) I'd be writing it in the Base Language NO MATTER WHAT, so that it would be Standard-Compliant and therefore MORE USEFUL to the WHOLE community.

Not what you wanted to hear, no, but that's the way its got to be if we go with a Standards-Based approach - and don't forget, I've been through this before (on a professional basis) and believe me, we DO NOT want to "throw the baby out with the bath water" standards-wise just because it puts some members of the community "out".

Finally, the above may seem harsh and/or dictatorial - I don't mean to be either; I am simply putting forward an idea or two for the community (and SmiteWorks, incidentally) to decide upon, for the good of us all - if people don't like what I've said or disagree with me, then that's fine. If the community decides to go with a different Language Standard, again, that's fine. I'm just trying to pass on some knowledge and experience for the benefit of the community.

++++++++++

OK, a couple of other things.

First, it would be a mistake for the community to go down the route of having some Rulesets written in the Base Language and some others written in various non-Base Languages with a Base Language Language Pak, because this defeats the whole purpose of having a Standard in the first place. If the community is going to have a Standard then it need to have ONLY ONE Standard - not a bunch of Standards. This is one reason that [B]ALL[/A] commercial aviation communication uses the same language - can you imagine what it would be like if any old language could be used in the commercial aviation industry?

Second, to avoid having to load multiple Language Paks (eg CoreRPG => 3.5DnD => etc), we could make the CoreRPG Language Pak(s) available in "raw" form (XML or LUA). Then if you are playing 3.5DnD you would grab the raw 3.5DnD Language Pak DIFFERENTIAL (that part of the 3.5DnD Language Pak different from the CoreRPG Language Pak and simply "merge" the two raw Paks together to form the actual Extension with then load. Similarly for "deeper" raw Language Paks.

Yes, its a bit more work INITALLY but I think its the best of both worlds from a maintenance point-of-view and a playability/loading point-of-view - again, just my $0.02 worth.

Cheers :D

Quote:

---

Originally Posted by dulux-oz

OK, I thought the answer was pretty implicit, but I'll make it explicit:

If we as a community go with a Standard (any Standard) then to be considered Standard-Compliant a Ruleset needs to be written in the Base Language - if there is also one or more Language Paks for languages OTHER THAN the Base Language then that's fantastic.

So, to answer your exact question (assuming that the community adopts the Language Pak Standard and English as the Base Language) the Ruleset that Blacky and bzjeurd are nearing beta on will need to be written in English (hopefully with a French Language Pak - and maybe others) to be Standard-Compliant. If they release their Ruleset and its not in English than it WON'T BE Standard-Compliant!

---

You are going in pretty heavy handed. There is no standard as of yet and there is no reason why the standard could simply require that all language strings support internationalisation.
This requires no more effort than doing it the other way.
There are many RPG's written in European languages (other than English) that have no following outside of their home countries which could be ported here. That would never happen if someone had to translate everything into English first when no English translation already exists. Who would translate it for a non existent audience?
Aviation uses a single standard that specifies language - because planes and pilots continually transit between different language zones. Games *may* not need the same standard.

The minimum standard may be as simple as a load order for rulesets and extensions and a requirement to support internationalisation of elements and functions.

Anyways - JPG has to work thru that once it gets to the top of his list - in the meantime lets try not to bruise each others toes :)

Now for my two cents: :)

I think that the language of any community rulesets should be completely up to the ruleset developer. I plan to put no limits on anybody willing to put forth the effort to build a ruleset, as it is a challenge enough. Any language packs are bonus.

As for rulesets sold through our store, I would say that the rulesets should be written with an English interface, mainly because the majority of our users speak English. (There may be a case for rulesets that are specific to a country not to be English by default, but we can discuss with the ruleset developer before adding to the store.)

At this point, any language extensions for SW-provided rulesets are a blessing given to us by those willing to take on the work.

Dulux-Oz, I agree that standards are very useful, and required in some cases. However, I'm not sure it is necessary at this point. Though, I'm sure there will be some extra work down the road because of the lack.

The challenge will continue to be how to keep extensions up to date as versions of the underlying rulesets change (including language packs, whether they are extensions or something else).

If FG continues to evolve and grow, we can look at some sort of "language" setting for Fantasy Grounds that can be defined in the Settings, and language packs can be installed and automatically loaded for each ruleset based on that settings. (i.e. no need for tracking extensions, etc.) And, fall back to base language if language not available for that ruleset. Of course, this is just brainstorming at this point, because I have no bandwidth. ;)

Cheers,
JPG

Quote:

---

Originally Posted by damned

You are going in pretty heavy handed. There is no standard as of yet and there is no reason why the standard could simply require that all language strings support internationalisation.

In the meantime lets try not to bruise each others toes :)

---

Yeah, but didn't I actually say exactly that (or at least imply it)? AND I said that (and sort of, kind of apologised for it) if the COMMUNITY decides on things then that's what we should be doing?

So, I'll be explicit again: :)

If I have offended anybody or trod on any toes than I am deeply, deeply sorry - that was not my intention at all. As I said, I was simply trying to provide some insight and experience to the community with the aim of helping to progress a discussion on the new functionality of languages and to propose and develop ONE POSSIBLE Standard as a starting point for what has the potential to quickly become "a great big pile of spaghetti". :p

Again, if I've upset people than I apologise.

Quote:

---

Originally Posted by dulux-oz

If we as a community go with a Standard (any Standard) then to be considered Standard-Compliant a Ruleset needs to be written in the Base Language - if there is also one or more Language Paks for languages OTHER THAN the Base Language then that's fantastic.

So, to answer your exact question (assuming that the community adopts the Language Pak Standard and English as the Base Language) the Ruleset that Blacky and bzjeurd are nearing beta on will need to be written in English (hopefully with a French Language Pak - and maybe others) to be Standard-Compliant. If they release their Ruleset and its not in English than it WON'T BE Standard-Compliant!

---

So your proposition is to make a standard that will right off the bat, right now, say to the world: “your roleplaying games do not exist for the Fantasy Grounds community if they weren't published in English at some point, in the same manner”? I mean… really?

I thought maybe I missed something. But it seems I didn't. So obviously, no, I don't think that's a valid proposition for any kind of community organization or standard. How could it be? It's physically impossible to write a ruleset in English for a game that does not have an English version whatsoever.

Standard isn't probably the best word. Right now, I'll stick to guidelines and best practices. What would be the goals of such guidelines and best practices?

1. To help the end-user. Facilitate its search for how to handle his games. For example if most localizations are done as an Extension, that's a different Google search that searching for “ruleset rolemaster Deutsch” in Google.
2. To help the ruleset author(s). For example their might be some technical disadvantages to do localization as a separate ruleset, having the best FG minds preemptively point that out would help beginners.
3. Lay foundations for the future. This future could be features (like automatic download of dependencies, like transparent updates, like a decent FG gaming library), or documentations (like new guides to write and maintain rulesets for FG 3.x), or community efforts (like shared maintenance of ruleset or localizations).

Probably even a few others.

And I think the gains of such guidelines should outweigh the (minimal if possible) hassle of sticking to it. I also think given the past attitude toward i18n, we should be careful on how we as a community address this and talk to people outside the very small percentage of FG users actually being here on those boards.

Quote:

---

Not what you wanted to hear

---

This has nothing to do with me (I have zero personal stake in this, my personal level of English is quite enough to translate and localize whatever I need for my gaming tables, and even at my abysmal coding level a quick&dirty localization of any ruleset is well within my means). But I also seriously doubt you could have any idea whatsoever on what I wanted to hear or not.

On another note, Moon Wizard about translations being purely as strings, I'm afraid that's not the case. There are several graphics with text (from the top of my head, the chat emote icons, or the tabs, or the windows titles to the left side, or in CoreRPG all the big sidebar buttons). All those graphics would need to be remade (right now from scratch since there's no source file available for those) and included in a language pack (whatever shape it would take in the end).

I missed the various answers before posting mine above.

One thing I could propose, to keep with this Base Language idea, is that the base language of a FG resource would be the original language of a game. The trouble I can see with this, is how a ruleset author can access the original language of a game? Let's say (again, purely hypothetical) I want to do a Kobols Ate My Baby! ruleset for my French tables. But I do not own the original English game. Will SmiteWork buy it and send me a copy? ;)

As far as I can see, there's no true gain for that base language thing, and several issues (but again as far as I can see, if I'm wrong please do tell). Maybe we should try another angle on this? Maybe FG resources could have clearer dependencies (something more visible than unzipping a .pak or .mod or .ext, reading through the code to find those) and more important a language string?

Like an attribute for the root tag, <root version="3.0.3" lang="en-US"> (en-US for USA, en-uk for great Britain, fr-fr for France, fr-ca for French Canada, just en for all English, and so on)? It do require some coding from Moon Wizard, something I would have prefered to avoid since he has no time for those right now but this seems like a very small thing. With no impact today, but there's a lot of inertia in the FG community (hell, I still use a ruleset that was abandoned before Goblin King sold it because there's no improved version that I know of). Whatever plans, guidelines, best practices are drawn today would take several months at the very very least to get hold of the beach.

This language tag would be optional for past resources of course, not for future ones. It's a small thing, but unless FG output some kind of error it will be overlooked.

This is something that would be both somewhat human readable and that would be machine readable. It could in the future be displayed inside FG launcher, and/or in the forums download, and/or the SmiteWorks library, and/or the community library, etc. And there's no need to reinvent the wheel, there's already widespread use and good documentation by the IETF and a couple of RFC I don't remember the numbers right now for this.

But again, just a question and a quick suggestion for this area of things.

Edit another thing to add. Maybe important, maybe not. But I doubt you know of it, so there it is. There's several FG ruleset/extension authors that don't speak English. Don't ask me how, I still don't understand how one can learn LUA and more difficult learn the various FG intricacies without reading at least some basic English, but there is. Again, not saying this is important or need to be taken into account, just putting it out here these people do exist.

Quote:

---

Originally Posted by Blacky

So your proposition is to make a standard that will right off the bat, right now, say to the world: “your roleplaying games do not exist for the Fantasy Grounds community if they weren't published in English at some point, in the same manner”? I mean… really?

---

That's not what I said - I said it wouldn't be Standard-Compliant. I also said:

Quote:

---

OK, so does that mean that they can't/shouldn't release their Ruleset?

Of course not!

What it does mean, however, is that until they do release it IN THE BASE LANGUAGE it won't be Standard-Compliant - so what does this mean? Nothing! Except that it may have a bearing on others using their Ruleset and basing their own variants on their Ruleset. Whether this is a problem or not is one that the community will have to judge.

---

Quote:

---

Originally Posted by Blacky

It's physically impossible to write a ruleset in English for a game that does not have an English version whatsoever.

---

I don't disagree with you - it's incredibly hard!

Quote:

---

Originally Posted by Blacky

Standard isn't probably the best word. Right now, I'll stick to guidelines and best practices.

---

I thought that's what we were doing, trying to come up with some guidelines and best practices with the aim of developing a Standard - I obviously misunderstood.

Its a good list. The "danger" I see is one (as I said a couple of times) I've seen professionally before - ESPECIALLY if we take Point 3 into account. I was just trying to avoid a "mess" in the future.

Quote:

---

Originally Posted by Blacky

This has nothing to do with me... But I also seriously doubt you could have any idea whatsoever on what I wanted to hear or not.

---

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". I would never attempt to presume what someone, ANYONE, was thinking. And that last sentence is indicating to me that it does "have something to do with you". So, let me apologise again:

If I have offended anybody or trod on any toes than I am deeply, deeply sorry! That was not my intent - I obviously let my big mouth run away with me again. :(

And I just did the same (missed the intervening post) :)

That's some very, very good ideas - I like them a lot (for what its worth). Plenty of things to consider. :)

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

Quote:

---

Originally Posted by dulux-oz

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) :)

Quote:

---

Originally Posted by 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).

---

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.

Quote:

---

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. ;)

---

:D

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 ^^).

Quote:

---

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.

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 :-)

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:

Code:

---

<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 ;) ).

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).

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

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.

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.

Quote:

---

Originally Posted by 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)?

---

Answered in post #8 with link to documentation! ;)

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

Quote:

---

Originally Posted by Trenloe

Answered in post #8 with link to documentation! ;)

---

I definitely need to find a new brain on eBay, ot a least a new set of eyes :o

Thanks to both.

So, what I was saying is maybe for localization, language pack guidelines, not to set those to 100 (loaded last, take precedence over anything) to leave some room for GM to do their own things without too much hassle.

Maybe something like anything regular will stay in the 89 percentiles, localization at 90, and anything above for personal home-brewed work?

I would propose to have the different language string resouce files in sub directories for each supported language within the rulesets or extensions itself. E.g. "PFRPG/strings/us (contains the default) ,PFRPG/strings/de , PFRPG/strings/fr, PFRPG/strings/it ...).
So the extension to change the language just switches the path to the strings resources to another subfolder for all string resources, also for all the other extensions which were activated with the ruleset.

In the last days i was working on a localization for the PFRPG ruleset into my native language (german). It was a little bit annoying that the UTF-8 encoding is still not implemented yet for FG3. This issue is under the top 15 wishes in the feature wishlist of FG3 and at the latest it sould be implemented if a standard localization mechanism should be established.
By the way, i noticed that there are still some "hardcoded" strings without string resources in some (all?) lua files (data_common.lua, manager_chat.lua ...).
It would be cool if that strings also could be outsourced to xml string resources as soon as possible.

To do the translation i wrote a script which created a .po file (GNU gettext mechanism) to be able to make use of a localization editor like poEdit.
For XML there is also a standard mechanism for localization, called XLIFF.
Maybe it would be a good idea to implement this functionlity for the strings resources so the community can make use of XLIFF editors.

Here is a description of XLIFF:
https://www.maxprograms.com/articles/xliff.html

Quote:

---

Originally Posted by drvolk

By the way, i noticed that there are still some "hardcoded" strings without string resources in some (all?) lua files (data_common.lua, manager_chat.lua ...).
It would be cool if that strings also could be outsourced to xml string resources as soon as possible.

---

If you could point out which strings exactly, it might help Moon Wizard outsourcing them out.

Within the attached "PFRPG localization to german" extension i implemented a workaround to "reinitialize" the Lua hash tables in the data_common.lua file , which contains for example the strings which were shown as "Skills" in the character sheet.

I can try to make a list of all other "strings" without a corresponding string resource, but this could take a while because i have to scan all lua files für such strings ...

UPDATE:
a file with all string constants assigned with "=" operator from lua code now is also attached.

Hallo at all,

I just found this and skimmed through the posts above. Therefore I just found that the extension of drvolk and did not know, that some else is working on this.

I am a user of the "Drachenzwinge" a German role playing community. I've started a translation for DnD 3.5 and Pathfinder after I saw the possibilities in the new ruleset with the string-folder. This translation is build as an extension, that also includes graphics (sidebar and tabs). The extension contains the string-xml-files of core and 3.5e, nearly every entry is translated. With a little dressing - shortening of too long words in German - it will be finished. At least as fare I can go until now. This means: It is not a 100% translation because of several reasons:

1. There are to variables which can not be translated without loosing ruleset functions. That are "ps_default_groupability" and "ps_default_groupsave". After translation the ruleset can not find a match, for example "Stärke" does not match "strength". And so the rolling does not work properly. [I already tested manipulation the data_common.lua, but I could not fix it.]
2. Some chat massages are not build with variables out of the string-folder. (as drvolk already noticed)

@drvolk: That is a nice extension and I tested also the manipulation of the data_common.lua. But there are the same problems with ruleset functions I found. So with your extension the ruleset is also broken, like my testing extension. For example the roles out of the partysheet (Ability and Save) is not working properly.

The translation extension is not completed. But soon it will go to beta-testing.

So fare to the background. Now to the questions:

1. Can I use edited graphics for the sidebar or do I have to draw complete new icons by my self?
2. I think the internationalization is still in progress so that one day all stings that are visualised on screen are either in the string-folders (easiest way) or in a graphic. Is this correct?
3. If so (2.) than will there be a complete separation between background names of abilities, skills and so on and the shown strings on the screen? (in the background of a ruleset every thing is working in English and on the screen it will be show in a specific language)

@drvolk:
1. Are you a member of the Drachenzwinge?
2. Can you in principle envisage that we work together on an extension?

With best regards

Lule

For the graphics, you might look at this: https://www.fantasygrounds.com/forum...hield%29-Icons

It will give you the source files. But you'll probably need to change the fonts, since they are English specific and doesn't handle much outside pure ascii.

Quote:

---

Originally Posted by Blacky

For the graphics, you might look at this: https://www.fantasygrounds.com/forum...hield%29-Icons

It will give you the source files. But you'll probably need to change the fonts, since they are English specific and doesn't handle much outside pure ascii.

---

Thank you!

Hi Lule,

i have also an account for the "Drachenzwinge" forum but i use it more as "readonly" member at the moment.

Of course i am willing work together with you and other people to realize a translation for FG3 and Pathfinder or D&D 3.5.
I did allready noticed the problems with the ruleset is broken, and i am working now on patches for all the lua scripts which are using strings which could be displayed or parsed and so on (it is done by a python script, the scripting language i am trying to learn more about ...).
It is a little bit triggi because you have to recognize if a string is just a "constant" or realy a "displayable" text. Also some translateable texts are used within regualar expressions and so on and so on ...

We could share our work and trying to bring it to common source. We could plan the tasks which should be done together and divide the work among us. How we should proceed ?

Hi drvolk,

first of all, I like to wait for an answer to the questions above from a developer of FG. The way you are trying is possible but a lot of work and must be done for every new version of the ruleset. The main problem is that there are some variables where the name = the name in the db.xml of a campain. With changing that some parts of the ruleset do not know where the data is stored. So the best way for any translation would be an intern name which is used in the db.xml and in the background of the ruleset and an extrenal name which is shown on the screen. That is a lot of work to do for the developer(s) of the ruleset. So I hope that there will be a progress step by step in the separation of the code.

As soon as I have the beta version of the extension I am working an, I can share it with you. But there is still the problem with skills in the charsheet for example. There is no easy way of translation that does not corrupt the functioning of the ruleset.

The best way for contact is: Please send me a PM in the FG Forum so that we can try to find appointment for a meeting on the TS-server of the DZ.

I am familiar with the FG-lua und FG-xml but not with phyton, as I am developing and maintaining together with other members of the DZ a ruleset for "The Dark Eye", a German roleplaying game system. I think you know that system. This project started long ago basing on the D20-ruleset and later on DnD-rulesets. Than the former developer stopped this project due to private reasons. With FG-Version 2.9.0 there the ruleset was not working properly any more. So a few members of the DZ decided to go one with the development and maintenance. The next big step is version 1.3.0 of this ruleset, which can hopefully released until summer. We are discussing if we change with 1.4.0 to layering on core. But if we do that, we will design the ruleset completely new.

Regards

Lule