Translate Shaarli to other languages

[qwertygc]

Hello Traduire shaarli ? Cordialement.

[nodiscc]

Hi, this was discussed at https://github.com/shaarli/Shaarli/issues/106#issuecomment-75469295, and originally at https://github.com/sebsauvage/Shaarli/issues/18. It was agreed we should use GNU gettext as the internationalization backend. Pull requests welcome.

[e2jk]

I posted an early sample code at https://github.com/sebsauvage/Shaarli/issues/18#issuecomment-14168240 I won't have time to push for it soon (I just started my 2 companies this month, yay), but feel free to take the code and run with it!

[nodiscc]

Another important question is, how do we select what language to display?

• server locale
• browser locale
• configuration setting
• let visitors choose

I'm in favor of a config setting.

[mrjovanovic]

Also vote for config setting, but default could perhaps go to server locale (I can see how that would be useful for deployment).

[nodiscc]

This fork https://github.com/broncowdd/Shinterest has multi language support

[blankoworld]

Hi all.

I don't understand what was done here to permit french translation (and other ones) on Shaarli.

How can I choose french language in current Shaarli?

[ArthurHoaro]

Hi. This issue is still open, so it's not possible for the moment. @nodiscc was pointing out that a fork did it, but did not merge it upstream.

Also, I'm not sure the gettext proposal by @e2jk is a very good idea, because of users on shared hosting. Gettext library needs to be installed, and translations are cached by Apache.

[blankoworld]

So if I understand it well, we need someone that check Shinterest code, then include it in Shaarli (current development version) and suggest a merge proposal here?

As I don't understand PHP language, it could be difficult, but copy/paste and modifying is possible :smile:

I can help for translations if needed.

[ArthurHoaro]

Well, first we need to agree on a translation system, as copy/pasting Shinterest code might not be the best way to go. I can work on this.

Then, every string displayed need to be processed through a translation function. Which means every template need to be heavily edited. Since we're entirely rewriting templates for v0.9.0, I suggest that we do that in the webdesign branch instead. Help appreciated on this.

[ArthurHoaro]

So after half an hour of digging through a lot of Google pages, I still have no clue if gettext is widely installed on shared hosting, but:

• big projects like Symfony, Wordpress and Drupal use their own gettext implementation (in PHP).
• this guy convinced me pretty well not to use it.

However, the PO format is suited for translations, including a lot of translation tools to work with. Other formats I can think of aren't really good for manual edit (JSON escaping with double back-slashes, INI and its bad PHP parser, YAML requires a lot of dependencies, etc.), and I don't really want to store translations in PHP arrays.

So, I suggest we use a *.po file parser library. This one seems good: https://github.com/raulferras/PHP-po-parser

I'd like @nodiscc and @virtualtam opinion on this.

[virtualtam]

Definitely in favor of using Gettext. It's a universal translation/localization format that is widely supported by each and every proper programming language/technology.

Translations can be versioned and updated along the codebase, and there are powerful tools to edit them:

• locally with Poedit + Pull Requests for peer-review
• online with Transifex which allows to manage translation teams

I still have no clue if gettext is widely installed on shared hosting

Localized Shaarli if it's installed & enabled, English fallback else. Gettext is universal enough that we shouldn't have to look for 3rd-party implementations.

PO format is suited for translations

Yup, and we can add Makefile targets to automate potfile generation and updates.

[ArthurHoaro]

Gettext is universal enough that we shouldn't have to look for 3rd-party implementations.

Honestly, I'm not sure it is (as I said, major PHP projects use their own implementation and doesn't require it). But yes, using an English fallback wouldn't hurt since everything is in English now.

Translations can be versioned and updated along the codebase, and there are powerful tools to edit them:

• locally with Poedit + Pull Requests for peer-review
• online with Transifex which allows to manage translation teams

Yup, that's why I wanted to keep PO files.

Since we disagree, I guess @nodiscc has the final word on this.

[virtualtam]

If we're settling for gettext (either PHP's extension or a 3rd-party lib), the functional base can be laid out (PO/potfile structure + MO/machine object generation); switching from an implementation to another should only require minor changes (though the helper _() alias seems to be reserved, thus available only when using the PHP extension)

[ArthurHoaro]

Yes. We can use a wrapper function for _().

[qwertygc]

Hello !

How is this functionality ?