Currently Lute stories all language defs in a separate language_defs repo in LuteOrg in GitHub. This works well in most cases.
With plugins, though, it's a bit of a hassle. When a new plugin is installed, for that plugin's language to show up under the "add new language" listing in Lute, it needs to be added to the lang_defs repo, so two different repo updates have to happen at the same time for the best user experience. It would be preferable for the plugins to supply their own definition.yml and sample stories, and for those to (potentially) be added automatically to the user's Lute database -- after all, they've installed the plugin.
Note: this might not have high ROI. There are likely only a few language parser plugins needed for special cases! This may be tricky to handle well, and therefore not worth doing.
Some issues to consider:
suppose the plugin provides a definition.yml with language name X, but the user already has language name X. What should happen?
Are language and stories auto-added on plugin start-up? If yes would need a system flag or something so that it doesn't repeatedly add the language. If system flag used, and user deletes the language def, he wouldn't be able to re-add it?
Older plugins won't have these files available, load shouldn't fail.
would the definition.yml be loaded from the plugin itself, or would the file somehow be copied to the language_defs directory in the Lute code folder? What if that folder already exists?
Currently Lute stories all language defs in a separate language_defs repo in LuteOrg in GitHub. This works well in most cases.
With plugins, though, it's a bit of a hassle. When a new plugin is installed, for that plugin's language to show up under the "add new language" listing in Lute, it needs to be added to the lang_defs repo, so two different repo updates have to happen at the same time for the best user experience. It would be preferable for the plugins to supply their own definition.yml and sample stories, and for those to (potentially) be added automatically to the user's Lute database -- after all, they've installed the plugin.
Note: this might not have high ROI. There are likely only a few language parser plugins needed for special cases! This may be tricky to handle well, and therefore not worth doing.
Some issues to consider: