See the past thread on kde-www:
https://mail.kde.org/pipermail/kde-www/2018-March/007037.html

Unless polylang is able to extract gettext files, or it would be possible to add some magic code which interfaces with it and imports and export gettext files, it does not fulfill the requirement.

What the translators would like is something that doesn't make them change their workflow.

That means they just get a .pot in the svn translations websites/ folder, they translate it, and it magically appears on the website, without anyone having to do more work than the usual work of translating and uploading the .po files like they do for the rest of our software.

I've been asking in #wordpress in freenode on the issue.

It seems like there's no straightforward way to extract po files to wordpress. On the other hand, there's not really any system in place. There is polylang that is a closed service and even there, we'd need to adapt to their workflow.

As a way forward, I see there's good APIs to interact with WP as well as po files. It shouldn't be too hard to have a service that daily does:

1. lists WP pages and creates / merges contents into po files
2. creates separate pages that we'll use when the user wants a specific language, if available

Does that make sense?

I was thinking about that yesterday when i saw the script Riddell has that creates pages, i guess it would be possible, there's two issues i can think of that make it non-trivial (i think):

• We somehow need to update pages to cross link to all the other languages pages (if we want to keep the header like language selection we have in the announcements now, i.e. the "Also Available in" https://www.kde.org/announcements/announce-applications-18.04-rc.php)
• We need a way to segment whole pages into sensible .pot translation units. You don't want the whole page to be a single .pot entry because it would mean exposing html stuff to translators, that is easy to make mistakes with, and also because if you change one word you want to "dirty" the smallest possible unit (ideally sentence, at realistically paragraph) for retranslation not the whole page.

Given that we have to head down the custom path here, the objective is to have as little custom code to maintain as possible, while still getting the job done.

My plan was to have pages "marked up" with some kind of marker to indicate blocks of content that should be translated. The plugin would then, when rendering pages check the user's language preference (set by cookie, and if that isn't available, inferred from the headers sent by the users browser as to the language they'd like) and use the appropriate gettext routines to translate the content within the blocks, and render it to the user.

The language selector would then be placed in the footer of all pages, and would function for the whole site, not just release announcements.

If necessary we can make it so that something in the URL denotes the language (either at the start or end), although I don't know how hard this would be to integrate within Wordpress and how it manages pages (Polylang manages it, but I don't know what it does to Wordpress' page management). If we were to do this then the user should be redirected on their first visit to the appropriate language version (per their browsers request headers).

The plugin would probably need to make sure it was the "first" within the rendering pipeline in Wordpress so that it didn't have to deal with other markup like URLs which had been processed by other plugins.

The markup would then make it possible to extract the page content to *.pot files for translators to work on (which the system could export every day or two - probably less when changes aren't being made as frequently, depending on how expensive this is) and the po files could simply be updated from a Subversion checkout.

I'm not sure how possible it is to build something like this within Wordpress, but from my understanding of how we want the Wordpress workflow to be, and how translators workflow must continue to be, this should satisfy both. The only question is whether it can be done in Wordpress - and if it can, how much maintenance burden such a customisation would create.

Would anyone in our community be able to create a script for localization?

Historically we've had a lacking of people able/willing to write PHP code for our sites.

Hi, I'm rewritten the docs.kde.org website with translation and more modern design in mind (see D17936). For the translation, I use simple yaml file with the format:

English text 1: Translation text 1
English text 2: Translation text 2

I could also change to the XLIFF format (xml based). Should I try instead to use po files? It shouldn't be too difficult to implement, just takes some time understanding it and implementing a special loader in symfony translation system.

And another question: That is the best way for the user to select the language? For the moment I have a language picker in the navbar, but I was thinking to also add a box with all languages available like in userbase in the footer.

In T8204#174644, @ognarb wrote:

Hi, I'm rewritten the docs.kde.org website with translation and more modern design in mind (see D17936).

Thanks for your work, but this ticket is about www.kde.org and the structure and the technology is totally different. Please recheck the past comments and the previous threads on kde-www.