In reference to the Italian localisation:
[05:40]robin: damn this translation is actually quite bad

Due to the aforementioned remark that was made concerning the low quality of the actual text in existing scripts, I'm also highly concerned that porting over the existing scripts might actually be more detrimental to furthering localisation development.

I've decided to make a repo here: https://github.com/flushedpancake/xmbforum-localisations

This should help aid people who want to contribute to creating localisation texts without having to interfere with the main repository. A link has been provided to the main repository English script for reference.

This would be a dream... but a great undertaking.

Quote: Originally posted by Xian

This would be a dream... but a great undertaking.

Yeah, it's a hard ask for a lot of people to just blindly translate text for a project they probably have never even heard of, especially one which isn't one of the major vendors.

I also refer to these as 'localisations' rather than 'translations' because of the different variations/dialects of languages, especially notable with Spanish and Portuguese, and to a lesser extent French...

Actually made a repo now.

Dunno if it'll get anywhere, but at least it means if someone wants to contribute something, it becomes a bit easier, I suppose.

Even just translating the bare minimum like some of the generic UI elements visible to normal users would be of great assistance. I'm well aware of the pitfalls of using machine translation on websites where you can submit data.

Starting small is how we start to make things great, after all. I still remember the hype around the 'unofficial' 1.9.12 before miqrogroove came back, and if I remember, it started out all from a couple of posts about random bugs lol

I looked at a bunch of crowdsource tools for this. The two best and free options were GlotPress and Zanata. They both seem to have one major downside: gettext and .po files are required.

If we want to get rid of the database storage (already done) and keep the PHP file format, then we don't need or even want the gettext extension. Where that leaves us, though, is a lack of any translation API.

Here is a nice example of a custom translation API:

https://github.com/fisharebest/localization

This guy does a lot of language-intensive programming. Note in the readme file he addresses "plural rules" which is a much more sophisticated concept than the dumb gettext API ever attempts. His library also supports PHP translation files

Doesn't gettext handle pluralisation by design?

That said, the .po file format is irksome at best IMO, so this solution honestly looks better to me.

Perhaps get in touch with the author?

I think you are right. The PHP docs for ngettext don't explain any of it. The plural handling is all explained in the GNU docs.

If the PHP format is self documenting then we shouldn't need help from the author.

The PHP format in that library is a single array, which is good, but the structure is a specific interpretation of the .po file format. It involves non-printing characters and other arcane syntax that I don't like for this.

This looks better:

https://symfony.com/doc/current/translation.html#basic-trans...

Allows PHP files. Uses something called ICU MessageFormat for strings that need multiple translations.

you when Symfony


that file format looks ridiculously simple, it could easily be adapted for XMB in an aftternoon or so I suppose. I say we go for it, and it has the bonus of pretty much having a guarantee of maintenance since its from a larger project.

can't say I blame you for putting so much trust in Symfony though, it genuinely seems to have a lot of good functionality and flexibility

This one will be official for now.

https://github.com/miqrogroove/xmb-translation

I needed to do some testing on the date translation logic. When I finish that part I will add the French file here for testing. This will be temporary because I plan to go back to editing the English file only.

There's still a long way to go for converting everything to UTF-8, adopting Symfony translate package, and setting up Weblate (if possible). After all that, we would have a better idea of the role of the repository.

The broken date logic from 1.9.8 SP2 has been corrected. If you switch to French and use a date format like "dd F yyyy" all dates will be displayed in French instead of English.