Integrate multilingual package

[mlocati]

We sometime talked about integrating the multilingual package into the core.

What about it?

[patrickheck]

I don't see any real disadvantages.

[mlocati]

And I see big advantages 😉

[aembler]

We had talked about this – it's something that's probably good to do. We wanted to get an interface into the core for actually doing the translation of the t-stringed files, too. We have one in internationalization enterprise but it requires a bit of server configuration. I know a third party package does this too – we'd love to get something like that into the core.

[mlocati]

We had talked about this – it's something that's probably good to do.

Great!

We wanted to get an interface into the core for actually doing the translation of the t-stringed files, too.

What are the target translatable strings? The core strings should be managed by Transifex, the strings in the packages can be worked on with my i18n.php..
IMHO what remains is not that much... 😉

Furtnermore, having a good PHP-only alternative to xgettext is not easy: it should take care of t(), t2() and tc() calls, and extract comments marked for instance like t(/*i18n: %s is a date*/ 'Posted on %s', $foo)...

[Remo]

what andrew means is this http://www.concrete5.org/files/4913/3699/0794/translations_manager_screenshot_4_1336990794.jpg (http://www.concrete5.org/marketplace/addons/translations-manager/). We've been working with this add-on and it's pretty awesome, but unfortunately, it's not 100% compatible with poedit..

[mlocati]

And which kind of strings does it extract? I mean, if they are in PHP files, then the PHP developer can extract them with other tools... At least that's what I'd do 😉

[Remo]

I believe it supports most if not all of those functions. That tool is aimed at users, not developers. We've had a few cases where customers translated their site on their own in which case it is nice not to send them the code and explain how to use xgettext etc.

[aembler]

Yeah – our internationalization enterprise tool also does a similar thing and is pretty reliable – but the amount of configuration required on a server to get it to run probably makes it not quite as nice as something that would just work out of the box. Remo is right: this really is aimed at end users to allow them to translate the t() strings in their site. This would also be one interface where we could also include attribute key names, group names, etc... so they could translate that dynamic content as well.

[Remo]

to me, these are two different things. One is the actual i18n functionality, site sections, browser language detection, early language detection so we can easily translate block actions etc. Having a UI to translate things is another story to me.

While it would be nice to have, I feel that the core functionality is the more important part at this point. But don't get me wrong, I don't think there's anything wrong with having localizer in the core. The translation manager by mainio doesn't require any kind of configuration by the way. It handles all the po, mo stuff with PHP code. That's nice on one hand, but probably also the reason why it isn't 100% compatible with poedit/xgettext..

[mlocati]

This would also be one interface where we could also include attribute key names, group names, etc... so they could translate that dynamic content as well.

Great! As I already told you some time ago, feel free to make any use you want of mine Localizer 😉

[aembler]

Ah, that's the one – I knew I remembered another package that was out
there that helped localize some of the dynamic items in concrete5.

On Tue, Aug 12, 2014 at 9:55 AM, Michele Locati notifications@github.com
wrote:

This would also be one interface where we could also include attribute key
names, group names, etc... so they could translate that dynamic content as
well.

Great! As I already told you some time ago, feel free to make any use you
want of mine Localizer https://github.com/mlocati/concrete5-localizer [image:
😉]

—
Reply to this email directly or view it on GitHub
#597 (comment)
.

Andrew Embler
CTO, concrete5
concrete5.org : andrewembler.com : facebook.com/aembler :
twitter.com/aembler

[mlocati]

Mine Localizer is able to handle translations for these contexts:
https://github.com/mlocati/concrete5-localizer/blob/master/controllers/dashboard/system/basics/localizer/options.php#L7-L18

[aembler]

I really want to do this still. Let's move it to 5.7.1

[ahukkanen]

@aembler How about some community help on this one? Sketch some plan on how the core stuff would would work and then distribute the work over to the community. We can throw in some amount of work into this.

We'd really like to get on to 5.7, we have a couple of projects starting up pretty soon that will require multilingual functionality.

Please also see this:
http://www.concrete5.org/community/forums/5-7-discussion/multilanguage-roadmap/

[aembler]

I have left a more detailed issue here:

#1505

I'm going to close this one. Once we've had a chance to go over the various requirements of that issue, feel free to post specific questions and I will do my best to answer them quickly. I'm deep into documentation and the forthcoming 5.7.2.1 but this is a very high priority as well.