An Idea for better Translation-Support

[Simerion]

In my opinion, even if you can translate individual texts and exchange ideas, FG has a small design flaw. The hard link to coding and description, and the use of terms in coding. I was thinking about how to make the translation easier with as few changes to the software as possible, as well as existing rulesets, modules and extensions. Mixing translated and untranslated content would probably also be possible.

Two approaches to split internal and external representation of an Element:
1. Give all Elements an optional link to a Translated version. If the link exists, use if for displaying. The internal (english) need no additional changes (only the link) and is used for Coding.
2. Use the english fields as internal, and allow an optional external field as external representation (e.g. with specified additional suffix or prefix). For displaying use the optional field, if it exists.

[Talyn]

It would require some architecture changes, but I had considered the possibility of using language coded filenames; ie. db-en.xml for English, db-br.xml for Brazilian, and so on.

However, no matter how it's done, when it comes to the retail DLC how do the commissions get handled? I get approved to do a Paizo project, in English, so I get the full commission. Then out of the blue, someone submits a Brazilian translation, which is incorporated into the retail DLC and therefore uses all the other assets I had to assemble myself, but now my commission is 50% with no warning. Someone else submits a Deutch translation, now I'm down to 33% commission with no warning. Great for the consumer, obviously, and let's be honest: no one is doing any of this to get rich, but still... the original developer did all the work and they will lose commission with each official translation, so it's not exactly incentive to do these projects to begin with considering the larger books tend to take a couple hundred hours to adapt for Fantasy Grounds.

The other alternative is for each translation to have it's own totally separate DLC purchase, which would be the easier solution in terms of getting the products out there, but also leads to more customers service transactions from users who were unaware of the translated products, and so forth, as well as varying product quality since each developer is building the project from scratch and not everyone uses the same practices and tools.

[Simerion]

It would require some architecture changes, but I had considered the possibility of using language coded filenames; ie. db-en.xml for English, db-br.xml for Brazilian, and so on.

I translate only for my own rounds. And i have many problems. Example: If i rename the temporary hit points (5e), effects doesn't trigger anymore (cast a spell that adds temp. hp), if i rename skills and add a class, he add the english skills...

Why string-files, if they doesn't work? There is no separation between internal (coding) and external (display) representation in FG. English may be a widely spoken language, but it is still not the mother tongue of many. It would be nice if you could at least translate the essential parts for your rounds without getting disadvantages because the programming is based on the display texts.

And as long as there are no official translations available for FGU, it would be nice to be able to help out yourself. Fine with me with the prohibition of passing on. It would also be nice if you could mix translated parts with untranslated parts (if the coding was based on internal texts, this would not be a problem. e.g. when adding skills, it would be checked against the internal name and not the display, when spell effects use the internal field names...).

[Talyn]

String replacement works great, and that's how LPak works, but only UI elements use string text. The actual data content we play with is stored in XML, and each ruleset uses its own unique data paths.

[Simerion]

String replacement works great, and that's how LPak works, but only UI elements use string text. The actual data content we play with is stored in XML, and each ruleset uses its own unique data paths.

LPak unfortunately does not work as expected (more on this below). FantasyGrounds is not bad software, but as a software developer (who also spent a few years in quality assurance), there are some things I don't hold back my criticism and think about how to make it better.

Need a mini-example why LPak just doesn't work? (5e Ruleset, only one skill and the Temp HP-Strings)

<?xml version="1.0" encoding="utf-8"?>

<root>
	<string name="skill_value_insight">Motiv erkennen</string>

	<string name="temphp">temporäre Trefferpunkte</string>
	<string name="ct_label_hptemp">tmp</string>
	<string name="ct_tooltip_hptemp">temporäre Trefferpunkte</string>
	<string name="char_label_hptemp">TMP</string>
	<string name="power_label_healtypetemp">TEMP</string>
</root>

I load only the extension with this strings, and the "D&D Player's Handbook". And create a cleric...

First problem: After adding the "Acolyte"-Background, i have an additional "Insight"-Skill, without Stat.
What I expected: Use the translated Insight-Skill "Motiv erkennen". A translation should not change the behaviour of a software. My expectation was, that the skill should have an "internal" identifier (Whether it's id, use of the name in the link...).

The second problem I found in my first test was fortunately no longer present: The spell "Aid" (2 level) has the healing effect "5 temporary". In my campaign, this effect did not work as it should. In the one I just created it works.

[LordEntrails]

As you noticed, FG automation does not use any type of internal string ID to key automation off of. As you can imagine, it is based upon architecture decisions made more than 15 years ago and would not be simple to change. And, without updating 1500 DLC products and affecting thousands of community creations, it would not be a simple thing to do.

That doesn't mean the devs wouldn't like to do it, it just means it is a large investment of resources and has not become enough of a priority for them to do. You can always help them prioritize by using the Wish List. Probably the most applicable existing item would be;
https://fg2app.idea.informer.com/proj/?ia=40990
https://fg2app.idea.informer.com/proj/?ia=84833

[Talyn]

If the translation thing took off, especially with an official focus, the responsible thing to do for all the rulesets that use any type of text parsing (5E comes to mind obviously, but 3.5E/PFRPG does it too) would be to put all those into strings so that the translated strings would also work with the automation. But as LE says, that'd be a Wish List item, so by all means file it so users can vote.

[Moon Wizard]

Translation of spell and attack text for automation in multiple languages is problematic; since a state machine would have to be written for every language supported. So, the entire system that parses text into actions would have to be replaced with something else.

The string resources were meant to make customizing the rest of the UI possible; but not the data packs. Making data packs available in multiple languages is something we'd like to do eventually; but unfortunately, it's a lot of work, and not anywhere near the top of our priorities right now.

Regards,
JPG

[Simerion]

Translation of spell and attack text for automation in multiple languages is problematic; since a state machine would have to be written for every language supported. So, the entire system that parses text into actions would have to be replaced with something else.

But there is definitely a way to solve this without changing more than a few calls:

1. use replaceable strings here too, but in special string files, where the user is aware that if he changes them, he must provide his own data. In other words: If someone absolutely wants to exchange texts for his rounds, he has to bear the consequences (in 5e e.g. offer own feats, classes, ...).

I would even be willing to prepare a lot of it for 5e and make it available to you, especially since I would have to adapt a lot of the classes, backgrounds, talents etc. for a setting for my groups anyway (I'm well aware that I can't use the overall result outside of my rounds, but at least I could send you the necessary adaptations to make the 5e ruleset a bit more generic, if desired; whereby I would probably only implement variant 1 bit by bit at first).

2. use more sophisticated methods/functions, where you can replace one text with another (so that the ruleset gets the English expressions anyway).

Example: In the file "manager_combat2.lua" (5e ruleset) there is the method "parseNPCPower" which uses a lot of hardcoded texts. Why not swap the query of "sName" into another method, which can be overwritten in an extension. I'm trying to show what I mean:

Short extract from the original code:

function parseNPCPower(rActor, nodePower, aEffects, bAllowSpellDataOverride)
	local sDisplay = DB.getValue(nodePower, "name", "");
	local aDisplayOptions = {};
	
	local sName = StringManager.trim(sDisplay:lower());
	if sName == "avoidance" then
        ...

A possible variant:

function getNPCPowerName(sDisplay)
    local sName = getNPCPowerName(StringManager.trim(sDisplay:lower()));
    -- A user can now override this and replaced translated strings to english without having to replace the whole parseNPCPower method (and parseNPCPower still gets what it expects).
    return sName;
end

function parseNPCPower(rActor, nodePower, aEffects, bAllowSpellDataOverride)
	local sDisplay = DB.getValue(nodePower, "name", "");
	local aDisplayOptions = {};
	
	local sName = getNPCPowerName(sDisplay);
	if sName == "avoidance" then
        ...

3. A Variant of 1+2: Instead of checking against a single hard-coded text, make the comparison against both the hard-coded text and an optionally translatable text (yes, costs some performance, but FG is not a real-time application either).

Possible variant (Bases on same original-snippet)

function isEqualText(sText, sCompareString, sCompareStringResource)
    if(sText == sCompareString)
        return true;

    if(sText == Interface.getString(sCompareStringResource))

    return false;
end

function parseNPCPower(rActor, nodePower, aEffects, bAllowSpellDataOverride)
	local sDisplay = DB.getValue(nodePower, "name", "");
	local aDisplayOptions = {};
	
	local sName = StringManager.trim(sDisplay:lower());
	if isEqualText(sName, "avoidance", "power_value_avoidance") then
        ...

In the same way you could add an optional string resource to many "StringManager" methods.

The second and third variants certainly also have problems. But as long as there is no word here that is written identically in both English and the foreign language, but has a completely different meaning, this should work. I can't think of an example in the area of RPG statistics, but let's take the English and German word "Gift": The German word means "poison" in English.

[Simerion]

Translation of spell and attack text for automation in multiple languages is problematic; since a state machine would have to be written for every language supported.

And a second attempt: My very first proposal also aimed at something else, so no state-machine would be necessary (but would require stronger changes):

If, without changing the identification and coding, you could simply swap the texts in the display, that would be perfectly sufficient. In other words: If all elements had optional fields in addition to the current fields, which are only and exclusively used for the display, but the original fields are still used for coding and identification. I can completely live with the fact that the English description, the English name and the English description of the game are stored in the record for the game master (and in a detail-view for the players). is in the record for the game master. But it would be nice if you could add an additional tab for each element, where you could overwrite these entries for the display, and only for that. It would be unproblematic if each record would keep its original identity (e.g. class name "rogue"), but would be displayed with a different text, if set.

Then (once implemented) it would not be a problem if the rules would use hard-coded texts, if the coding would be taken from the English texts...