Add translation compilation to build process

[Rumperuu]

I've noticed that we are currently tracking both .po(t) and .mo files within the src/languages/ dir. in version control.

I'm not familiar with WordPress translation, but from what I can gather the .mo files are compiled versions of the .po files. @lolzim would it be better to remove the .mo files from version control and to add a compilation step to the build process, or do the .mo files need to be present even in the development environment?

[markcheret]

I'm not even sure if we need any of those files, since the translation is a community effort: https://translate.wordpress.org/projects/wp-plugins/footnotes/
I'm sure there is some documentation on how it’s done technically to accommodate this process.

[lolzim]

To me, it seems smarter to remove .mo files from tree and generate them at relaese time. So we can edit .po files even without havig gettetxt / poedit to generate .mo files.

That said, the original translations are using those .po/.mo files and as we can see in wordpress.com that a lot of translations are missing, even if there are files; there should probably be a bridge between .po/.mo & WP dev tools, but I have no experience on what is the 'official' way to handle plugin i18n

[markcheret]

I recently uploaded all the .mo files to the WP translation base. It could only match 29 or so translated strings per language. IMO it's worth checking into the mechanisms as it looks like i18n can be done using https://translate.wordpress.org/projects/wp-plugins/footnotes/ with up-to-date translation strings. Since the naming convention in the plugin changed recently there should also be a way to adapt the existing translation files and re-upload them producing a higher match rate.
I'm also happy to reduce the number of files we're shipping and maintaining and would use the mechanism provided

[lolzim]

OK, I'll check that within 48h and KYIT.

[Rumperuu]

On the same topic, is the wpml-config.xml file still necessary? AFAICT it is a config. file that is read by a specific WP Plugin (WPML). It was introduced by @markcheret back in 2014 and hasn't been touched since.

[markcheret]

On the same topic, is the wpml-config.xml file still necessary? AFAICT it is a config. file that is read by a specific WP Plugin (WPML). It was introduced by @markcheret back in 2014 and hasn't been touched since.

I honestly believe that the world has moved on from needing this file. It can also easily be restored if someone complains after it's gone.

[Rumperuu]

Something else I've just noticed during #152 — am I correct in thinking that the load_text_domain() method in languages.php doesn't actually do anything useful?

The function calls the private class method load() and passes the current locale as an argument, but the load() method never actually uses the $p_str_language_code parameter.

[lolzim]

For i18n, I added a few translations, I think I got the main principles.
@markcheret : it seems you have to "tell" WP that that guy is making the DE translation, this other guy is make the FR and so on:
https://make.wordpress.org/polyglots/handbook/plugin-theme-authors-guide/pte-request/#plugintheme-author-translation-reviewpte-request
This way, each 'translation editor' would then be recognized as such by WP.

It is not clear to me if you can set a single line for de_CH, de_DE & de_AT for example.

[markcheret]

I requested all of these with the Wordpress team:
https://make.wordpress.org/polyglots/2021/04/19/pte-request-for-footnotes/
Yours I handled with a guy from the WP polyglots support team in Slack.

[lolzim]

OK, I suppose it takes a little time. Page
https://translate.wordpress.org/locale/fr/default/wp-plugins/footnotes/
still reads

I'll check later.

[Rumperuu]

On the same topic, is the wpml-config.xml file still necessary? AFAICT it is a config. file that is read by a specific WP Plugin (WPML). It was introduced by @markcheret back in 2014 and hasn't been touched since.

I honestly believe that the world has moved on from needing this file. It can also easily be restored if someone complains after it's gone.

I've looked a bit more into it for #190 - WPML has a large installbase and we evidently have users that use it, so wpml-config.xml should remain.

@markcheret if you wanted to develop our WPML compatibility a bit, you could look into their Go Global scheme here - they publicise compatible Plugins on their site, which might be nice

[lolzim]

Speaking from a 4 official languages country, I can say that more than 2/3 of our WP customers are using it.