Module not visible/usable for other systems about fvtt-module-polyglot HOT 13 CLOSED

Thanks! It wasn't my idea, someone suggested it in FVTT chat and I agreed that it's a great idea so I did it :p

There's nothing preventing it from working with other systems other than the fact that I don't know if other systems also have a concept of languages or where they store the list of languages for that system.
Each system is unique and stores the languages it supports in whatever variable they want. I spoke a few days ago with a system developer who asked me a similar question and the answer was :

• Add your system to polyglot's module.json as supported
• Change the code so there's an if/else based on the game.system.name and use the proper variable (instead of CONFIG.DND5E.Languages)
• Send a pull request.

from fvtt-module-polyglot.

Not every system is public (e.g. someone is homebrewing something or just not ready to publish it), and you can't just add every potential system that wants to use Polyglot to your manifest. Maybe it's worth removing system restrictions and using some different approach for checking support? For example:

1. Check something like CONFIG[game.system.id.toUpperCase()].polyglot.supported
2. To get languages of character: either use something like CONFIG[game.system.id.toUpperCase()].polyglot.getActorLanguage or fallback to current implementation (actor.data.data.traits.languages.value)
3. Document how custom systems can be supported.

So config would be something like this:

CONFIG.SOMESYSTEM.polyglot = {
  "supported": true,
  "getActorLanguage": function (actor) {return actor.data.data.traits.languages.value},
};

CONFIG.SOMESYSTEM.languages = ["a", "b"]; // or just use settings to add custom languages

from fvtt-module-polyglot.

That's not really a usable solution either as it would imply every system would need to add support for polyglot individually, rather than polyglot adding support for every system. I prefer to control it on my side and say "these languages are supported" rather than depend on the system itself doing it. I just added pf1 and pf2 support recently for example.
The other issue with your suggestion is that it would mean the module could be enabled for systems that aren't supported and would be considered a 'universal' module even though it is not. It's better for users to see "ok, it doesn't support this system" rather than think it does, enable it, then see it not working. I'd get a lot more complaints that way as well.
Finally, if a system is in development, I'm sure the developer can modify polyglot's manifest just as easily as adding polyglot specific code into their system (which, really, shouldn't be there).

from fvtt-module-polyglot.

Your arguments sound reasonable... But still it would be great to make it easier to add to any system... Ideally I think that some universal base module should be there and some "system-modules" too. Like this:

• polyglot-base: universal module
• polyglot: system dependent module that enables support for: dnd, pf, etc, depends on polyglot-base (I think manifests do not yet allow this?)
• polyglot-foo: module that enables polyglot for some foo system.

Maybe that's not the best approach too, but making it easier to integrate to custom systems is something worth investigating.

from fvtt-module-polyglot.

You realize that polyglot is less than 200 lines of code.
Adding support for a system would take 3 changes, each of which would be a single line of code.

• Adding where the language list is
• Adding which attribute in a character sheet contains the character's languages
• Adding the system to module.json

This small change added support for both pf1, pf2e and refactor the way languages are fetched for various systems: 15833f2

I don't think that splitting the module into 3 separate modules would make it any "easier". It would make it more complicated, to me, to the system developer, and to the users. I have no idea why you're thinking that changing 3 lines as needed is the end of the world.

from fvtt-module-polyglot.

@kakaroto your module is good. I'm just not happy with the approach of needing PR to enable a feature in some system.

I wanted to "brain-storm" the potential solutions to this "problem": How to make this module really pluggable? I understand that for such small module splitting it into "base" and "per" system is not a very good idea. Maybe I should have just brought that discussion right into Discord instead of bringing it up here: your module is really not a best example to show "hey we need some more complex dependencies for manifest.json"

from fvtt-module-polyglot.

I understand that, I just don't see how it can be made simpler, unless systems follow specific rules. pf1 and pf2e used the same CONFIG variable name and the same actor attribute name, so it was easy. I looked at wfrp, but it didn't seem to follow the same rules (not sure it even has languages), and fate didn't have any language support.
Needing a PR is not a big deal. Each system is independent and can be made in different ways.
I understand the frustration though, I'm also not a fan of how Foundry expects us to update our modules at every release updating the 'compatibleVersion' to the manifest.json just so it gets loaded (now it allows it load but displays a warning to users).

from fvtt-module-polyglot.

@kakaroto - So I have interest in this as well, specifically for WFRP. I am happy to do a PR but I also feel there should be a way to make it easier to integrate.

Each module has their own config menu available at Configure Settings->Module Settings. So there would only really need to be two fields to configure there, from my understanding.

Path - "actor.data.data.traits.languages.value" // Could default to D&D data location
Default Language - "common" // Again defaulting to D&D

So specific system support would not have to be specified, just where the languages array is. And if the data is not in an array, then I could see requiring a PR or a FORK of the project.

from fvtt-module-polyglot.

@kurlin that's definitely not an approach I'd want to take because you'd allienate every person who doesn't know how their system works internally (and nobody is expected to) and you're making everyone have to configure the module to make it work instead of a single person (me or the one doing the PR) making it work and it works for everyone
I don't think that making those variables into configuration options is the best way from a user experience perspective.
I looked at WFRP briefly but didn't figure it out. I was later told by the dev that with WFRP, the languages are items in the character sheet (skills of type language) which means your idea wouldn't work either since there's no field that contains an array of languages and it would require custom code to actually infer the language list based on the sheet's items collection.

If you can work on this and send a PR, I'd be very grateful and merge it!
Thanks!

from fvtt-module-polyglot.

Fair point. I will take a look and play around with it.

from fvtt-module-polyglot.

@kakaroto I have it loading the languages correctly. Though there are some UI issues, will see if I can work it out with the WFRP module owner, as I think it is due to the styling of that system.

from fvtt-module-polyglot.

@kakaroto added a PR #14

from fvtt-module-polyglot.

Closing this as it's not really an issue that I need to keep track of. Feel free to open PRs which add support for additional systems.

from fvtt-module-polyglot.