Symphony.

ooh, does this mean all discussed features (decoupling from Language Redirection etc.) are implemented? Awe.some.

If so: I totally did not realize it and will try this extension out a.s.a.p. Thanks a lot Remie!

Yep, it is all there, including 2 parsers: PO and JAVA-style properties. Basically the entire issue list has been fixed :)

Enjoy!

@Remie (after some time) I am finally about to start with the localisation of my project and I am looking forward to working with this extension.

A couple of questions related to localizing an existing Symphony website using this gettext extension:

I have a working Symphony website (NL) that should be localized (EN, DE, FR, etc): many little resource strings/labels should be translated. Besides: I need this (localized) website to function as a prototype for other (very similar) sites (in other languages). What would be the best way to set this up?

I am thinking of branching my current (NL) project off in a 'localized' branch and implementing gettext there. When this is done I could use this branch as the 'default (EN) prototype' and create forks/branches for other sites (NL, DE, FR, etc).

Although the sites are nearly identical they could diverge re: styling/functionality so that's why I want to use branches/forks. Would a Git fork be more appropriate than a branche?

Also: I like the .PO approach best (most familiar to me, plus there are tools like po-edit) but I understand the .PO parser does not work with the XSL Parameters? So this forces me to use the XML DS and the xsl:key() approach. The latter looks a bit verbose to me but I assume I need to add the <xsl:key name="resources" ../> only once, correct?

Anyway, I hope to be able to soon report back with much praise for your work ;) Thanks!

I have a working Symphony website (NL) that should be localized (EN, DE, FR, etc): many little resource strings/labels should be translated. Besides: I need this (localized) website to function as a prototype for other (very similar) sites (in other languages). What would be the best way to set this up?

I'm about to embark on something similar, so would be interested in the answer.

Probably warrants another thread re: Git/workflow etc… Something like "Advice on managing Symphony Clones"

I just mentioned it here since gettext is a big part of my setup.

@David: I will get back to you on this question tomorrow evening! Perhaps we can create an ensemble for a multi-language site that you can use as a template?

@Remie thanks. I already have a working (live!) multilingual (re:content) Symphony project (NL) that should be 'converted' to a localized version. In the process this site should be made a generic 'prototype' for other localized sites.

But this seems more of a Git-branching issue. I'd rather stay away from ensembles to be honest ;)

Sorry for jumping in this one:

I have a working Symphony website (NL) that should be localized (EN, DE, FR, etc): many little resource strings/labels should be translated. Besides: I need this (localized) website to function as a prototype for other (very similar) sites (in other languages). What would be the best way to set this up?

You should give Frontend Localisation a try before deciding. If @remie has time to help, it will even support GNU PO and JAVA properties. I don't really have time atm to take care of them, but it's all set up to plug them in.

Hi @vladG and thanks. However, I am particularly interested in gettext since it does exactly whay I need: I already have a working (multilingual) site. The entries are available in multiple languages. What is missing is a localisation: making all static front-end 'resources' (labels) translateable. This is exactly what gettext will provide.

Because my site uses some 'hardcoded' language setting I like the fact that gettext is decoupled from e.g. the Lanuage URL extension etc.

So, for this project I believe gettext is the better match, but I'll be sure to revisit Frontend Localisation for another ML project.

@David

To answer your question about branching / tagging: The whole point of this extension is that you can support multiple languages for a single site. So you can have multiple PO files for multiple languages that contain translations for the same strings.

So if I understand your setup correct, you will create a "base" copy of your workspace and branch / fork this for the other sites were you might make small adjustments but still have the ability to import generic changes from the "base" branch.

If this description of your setup is correct, I would suggest create a separate repo for your PO files and add this as a submodule to your multiple projects. That way you can have the resource translations in a single place and use the same set of strings in all your projects instead of having to update multiple PO files if you change a single string value.

The second question is about using the PO files. It is indeed correct that you cannot use XSLT parameters with the PO implementation. This is due to the specification of PO files which allow you to use entire sentences (including special characters) as the resource identifier. XLST parameters are key/value pairs that do not respond well to space, comma's etc. I could create handles for the sentence, but that would make very strange parameter names like $please-enter-a-valid-emailaddress.

So yes, PO files can only be used in combination with the xsl:key element. And yes, you only need to include this once in your master template. I believe the extension has documentation about how to use this. If not, please let me know and I will give you an example.

I hope this answers all your questions, please let me know if it works!

@Vlad: I hadn't yet realized that you needed help with implementing the gettext() parsers for the FrontEnd Localization extension. After I finish working on #669 I will look into it!

@Remie, le thanks. Good suggestion to use a submodule for the PO files, I'll do that. My setup is actually a bit more involved: I use 1 repo for the main Sym install with submodules for extensions, 1 other repo for the workspace, and now 1 for the PO files. I'll need to 'clone' the workspace for each different site.

Anyway, I'll report back on how gettext works for me.

@Remie I'm implementing the Java-style at the moment and it works fine.

I do have a couple of questions, though:

• Minor tweak, I've added the $regionCode as <xsl:variable name="regionCode" select="'nl-NL'"/> (notice the inner single quotes to indicate a string). Using <xsl:key name="translate" match="/data/resources/resource[@regionCode='$regionCode']/item" use="@name" /> does not properly resolve because of the strings around [@regionCode='$regionCode'] Took me a while to figure out :) [@regionCode=$regionCode] works fine.
• I am wondering about performance: I foresee my Resources DS to become quite large. I could not find any caching setting in your DS but, in my case, I'd need to cache it. Would it be better to use parameters?
• How does one handle HTML in the translation strings? I could not find much re escaping code. I need to escape HTML in the key() attributes, obviously, but what to put in the .properties file? All HTML in the values is stripped and the rest outputted as-such. Is this even possible or do I need to break my string apart?

@David:

1. Thanks for the remark on the documentation, I've adjusted it. Sorry for the inconvenience of having to puzzle to get it working.
2. There is indeed no caching implemented in the extension. I do not know if this is the right place for it. I would assume that a cache implementation would be done on a higher level and not in each separate extension? If you have a large dataset, the parameters option will probably be slower compared to xsl:key.
3. You're not supposed to put HTML in your resource string ;) I can see the use-case though, for instance if you have an anchor or want to add styling to a specific word. This has not been considered as a feature. If you need it, please create an issue and I will try to implement it.

@Remie, thanks for your reply.

1. Thanks, although the docs are quite good there are a couple of things that could make it easier (for i10n n00bs like me ;) Will keep in touch!
2. AFAIK caching in 'normal' DS'es is defined in the DS itself. I assumed your extension DS used the same. You're right re: caching-in-extensions, this should prolly be done on a higher level. For Extension-DS'es: I'm not sure. Anyhow: caching would be a nice feat, maybe @nickdunn et. al. could chime in regarding the implementation?
3. :) That's what I thought. It's no big deal since I could break my strings apart or use concat(…) etc. It would be nice (but so would printf()-like stuff! ;)

re 3.: no need for an issue methinks. Mainly another addition to documentation. Thanks again!

PS: I am surprised with the ease of using the Java .properties files. So simple; even key's with whitespace Just Work™.

I did run into some issues with PO files. As you've mentioned the format is very specific. E.g. files generated using PO-EDIT fail (no whitespace at start, extra empty msid's etc)

I have no experience with using PO-EDIT... I tried to follow the specification, but perhaps I've been to strict?

Anyway, JAVA style properties are indeed easier and have the added benefit of being able to be used as parameters. Although I don't think I added support in the parameter parser for whitespaces in keys :)

I am using the DS a.t.m. and that seems to work great. Thanks! PS: I have added some suggestions on Github. They're that: suggestions but (I feel) would make this extension even more awesomer…

hi there,

maybe this has already been answered but i could not find anything about it. has someone come up with a managable way to call in a translation from an xml (value-of, call-template ...) and pass variable parts. like you would do in php

__('some %s content', $variable);

thanks
daniel

Daniel, I don't think this is possible at the moment. Remy's gettext extension outputs complete strings.

This means you'd have to split the strings in your .properties file yourself (EN=NL):

some=wat
content=inhoud

And then you could use concat(): <xsl:value-of select="concat(key('translate','some'), ' ', $variable, ' ', key('translate','content'))" />

It's a bit of a hassle ut I don't think there's another way.

Hi! There is indeed no way to do this. The problem is that the strings are added to the XML before the XSLT is applied. So you will need to work with the functions XSLT provides to parse the string data.

I would suggest using the EXSLT replace() function to make this work. You can leave the %s in the string and do the replacement in your XSLT.

Please make sure that you check if your hosting provider supports EXSLT functions!