Different Language System

[twin marten]

Imo one flat file would be much easier than trying to navigate through a hierarchy of files

The search function exists

[stuck plaza]

Yea, I have been thinking about this too and from a psychological standpoint, I can see why. However, my messages file is already approaching 1000+ lines. It easily surpasses that when you account for spacing and comments. I don't know about you, but when I see large message files like the essentials messages file, I get annoyed with just how much I need to configure in one sitting.

Of course, this is part of the trade off of customizability, but at the same time, it's a lot easier to work in chunks at a time.

There is a little more than just the reasons listed above as to why I want to continue pursuing this.

Part of which is to make it easier for future translators. If I have multiple people wanting to provide translations, I could split up the work between multiple people by having them work on one file instead of all of them racing to translate the same file.

I'm currently designing a new file structure that I'm wanting to use for my language system. A sort of "language pack" if you would. I'd appreciate some feedback on it.

Here's an example of the directory structure.

.
├── locale_en
│   ├── default_messages
│   │   ├── default_guis_en.yml
│   │   └── default_locale_en.yml
│   ├── holiday_overrides
│   │   └── christmas_override_en.yml
│   ├── locale_en.yml
│   └── locale_guis_en.yml
└── locale_pl
    ├── default_messages
    │   ├── default_guis_pl.yml
    │   └── default_locale_pl.yml
    ├── holiday_overrides
    │   └── christmas_override_pl.yml
    ├── locale_guis_pl.yml
    └── locale_pl.yml

In this example, I have taken a different approach to the standard one language file most plugins use. There is still a general language file, but it only contains the general messages and error messages. Everything else that can be categorized would be put in a new file. In this case, language options for GUI items are put into a separate file.

Now, I believe that this will offer more benefits than drawbacks.

Benefits
+ Modularity
If a server owner disables a part of the plugin's functionality, lets say the GUIs for instance, the GUI locale files wouldn't need to be loaded, saving some memory. Compared to the standard language file, all of those extra sections would just be taking up unnecessary ram. (I know it probably isn't much, but hey, just because you have an abundance of RAM lying around is no excuse to use it unnecessarily!)

+ Expandability
If I wanted to add any future subdirectories, it would be extremely easy.

+ You don't have to delete files to get an updated version from a plugin update. (At least not as often)
In this case, the only files that would are the ones in the default_messages folder because this folder would be used to grab default/backup values incase of mismatched files.
Unless something new is added to an existing file, you can set it and forget it. Say for instance, you are using development builds of a plugin and the dev is changing GUIs pretty often. You wouldn't want to have to delete your language file every single time just to get some new sections. Not to mention all of the work you would have to do to re-update every section with the proper colors and messages.

Drawbacks
- Makes it a little more time consuming to setup.
Files like the holiday overrides section would likely have different color formatting and different holiday themed messages. Adding more work for the initial setup.

- Sacrifices some User Friendliness for Functionality.
it would be a little daunting to look at for the first time. As developers, this probably seems pretty straightforward, however, for normal server owners, they are used to the convenience of things being in one file. It wouldn't cause plugin functionality to break if they only modified one file, but would look incomplete if a server owner thought that they only needed to modify the general file.

- Harder to implement into code.
With an infinite expandable system like this, some hard coded methods would need to be made. As this system is intended for translations, sections need to be mapped to proper message values. Things like the plugin prefix which is located in the general language file would need to be used in every other file. Essentially coupling the general language file to every other one.
Also, dealing with multiple files could be a little problematic if they aren't managed properly.

These drawbacks aren't the biggest thing in the world, but Ease of Use and Ease of Understanding is nothing but a benefit to the end user. It would be nice if this system could be made a little friendlier, but with the way the files are laid out and labeled, it should hopefully be as straightforward as possible.

That's what I think at least, but what do you guys think?

[fierce vault]

Well, I think it may be unnecessary to decide it into multiple languages, when anyone is still gonna use one at the time. And when they want to use different language, they would just replace the files with the new language.

[stuck plaza]

Well this system kinda defeats the need to copy and paste language files. The end user would just need to change one variable in the config or use the GUI/In-Game commands to change language settings and the plugin would handle the rest. The files would be created on plugin startup and it could be adjusted to become hotswapable. It could also be adjusted to download new packs from github or smth incase the default translations are incorrect.