petition to SmiteWorks to implement full localization support into their rulesets

[drvolk]

With the LPak project, duluz-os started a community project with the goal of using FantasyGround to play all the directly supported roleplaying systems in other languages such as English.
This is realized by rule set extensions that exchange all XML text resources with translated XML text resources.

Unfortunately, not all of the displayed texts are stored as text resources in the rulesets.
On the one hand there are texts that have been rendered into graphics. These graphics must then be replaced by new graphics with correspondingly translated texts within the framework of the LPaks with appropriate effort using image processing tools.
Then there are also texts that are used as keywords for evaluating game content such as descriptions of monsters or objects.
These are directly stored in the corresponding LUA scripts as English texts and unfortunately not in the form of text resources which could be exchanged within the LPaks.
In addition, some LUA tables have data structures in which the English table index is also used as text for parsing or display on the user interface.

Some more complex rulesets parse not only individual terms in a content but also the stored grammar.
Unfortunately, this cannot be translated so easily by exchanging text resources.

With this petition I would like to ask the developers of the rulesets directly supported by FantasyGround to revise them in a way that a complete translation in the context of LPak extensions is supported by exchanging text resources alone.

On the one hand this could be another unique selling point for FantasyGround compared to the competition, which could be used for advertising.
On the other hand this could also motivate non-English speaking publishers to prepare their content for FantasyGround and make it available.
I am sure that there are some RPG players who would like to play virtual roleplaying campaigns but have been discouraged from doing so because the currently available solutions do not allow this in their own language or only very rudimentary.


It would be great if as many community members as possible would participate in this vote.


Translated with www.DeepL.com/Translator (free version)

[damned]

Whilst I would very much like to see this the devs have already stated, even as recently as this week, that they dont have the resources to do it at the moment.

[Naurthoron]

I agree that it will be difficult for legacy, but I believe this should become standard good practice for any new development.

[Simerion]

I agree that it will be difficult for legacy, but I believe this should become standard good practice for any new development.

Yes, but I have experienced at first hand what a subsequent introduction of internationalization into an existing application means (that's why I have also tried to name possible solutions how this could be achieved with as few changes as possible, at least in the initial stages). So I understand both sides, even if I hope that at least a first compromise will be reached (even if, as I described elsewhere, only the possibility to show an additional column in which you can display a translated term as well as the English one - then the coding still works, but you have some help).