Nicer to use systems for working with i18n.
Opened this issue · 3 comments
The translation process is too complicated and not that well organized. I think it would be much better to have a yaml file (or something similar) for each language and everything else should be done automatically.
You could even use something like crowdin.com for even more friendly experience for translators. I think it's free for open source projects
I agree it's harder than it should be for people doing the localization. The current system does, however, offer a bulletproof user experience once the localisation is done, and I wouldn't want to shift to something less robust—the current system means we get build-time checks that all the strings used in the code exist and doesn't let things get missed.
The ideal solution is probably some kind of automation to go from an easier to work with format to the current system in a largely automated way to try and get the best of both worlds, but that'd probably be a lot of work. I doubt it's something I'll be able to get to any time soon, but if someone wanted to make something I'd welcome it.
While for a lot of languages it isn't a problem, without the current system it would be close to impossible to implement a 100% correct Polish translation.
Some languages, Polish included, rely heavily on declination on a lot of things, including even nouns, and while most apps don't bother with that and just insert any nouns into the text, it technically is not correct and does not feel natural. If the only placeholders there are are names and such, it's not a problem, but Massive Decks often uses them to add things like icons or tooltips to improve user experience. Even if we avoided abundant placeholders, it's almost unavoidable with paucal plural (or even separate dual forms, really) which causes noun forms to change depending on the exact number of them—as before, most translators don't have a choice, as implementing them without scripting is impossible.
I also personally disagree with using anything like crowdin. It can make translating easier for users, but often leads to many mistakes and inconsistencies, some translations like that have phrases that seem almost incorrect and that are very hard to understand. Keeping translations here ensure that possibly the only people that will take up translating will be at least somehow experienced in this kind of stuff, and that all the strings will be done by the same person or group of people, which of course avoids most inconsistencies.
There is always a trade-off between quality of localisation and getting localisations of any kind.
I'm sure that if there is no localisation for the language someone speaks, they'd rather have a rough one than none at all, but when there is a passable localisation it can discourage the creation of a good one.
I don't think there is a single best answer here, there are upsides and downsides to different solutions, but for now given the number of quality localisations that have already been contributed, switching to a less rigorous system would be mistake.
With that said, I think working with the system as it stands is complicated for a potential localiser, and I would like to improve it some day with better tooling and guides. Just automating some of the boilerplate and some basic tests would go a long way to making it easier for people to contribute.