Tuesday 22 July 2008 3:08:29 pm

To enable english translation without hacking the kernel there is another workaround: you can simply declare your site to be using eng-US, and copy the translation files from eng-GB over the american ones. Or, you can define a new locale and copy over the locale definition from eng-GB...

Principal Consultant International Business
Member of the Community Project Board

Wednesday 23 July 2008 2:05:42 am

We're in the middle of discussion on how to deal with issues right now. It's great that you share your experiences - so big thanks! I'll try to share some more thoughts when I have time, but right now only one thing:

after long confusion of what policy to use for contexts, i finally decided to simply use the path of the template or php file in which the word appears. so the above example would be inside /design/mysite/test.tpl. this does not make much sense to the translators, but all the words will still be chucked together nicely, and translators will recognize the clusters from the front end. there may be a bit of duplication, but since most of your duplicate code will end up in include files anyway, not much.
And as a big plus, whenever I see the word foo in the dictionary, I know where to find it in the templates or php, and vice versa, quickly and efficiently !

I'm not sure I like this approach. Yes, it is tempting to make things easier, but...

Seems to me that the idea behind context is a bit different (although I may be wrong). I stick to more semantic side of context, so for example if I have an extension with lots of validation messages, I group them under one context. If there's a module that does something specific, it deserves its own context, etc.

With your approach (template paths as contexts), I expect lots of unnecessary (expensive) redundancy as well as problems if application changes its structure etc, which is actually very likely to happen to any app. Also, the context name may reflect some meaningful information that may not be part of the path.

One more thing: we've divided extension development process into two separate, subsequent phases: Developers use UTF-8 in the templates and skip translation layer, using Polish language directly. This saves a lot of time, lots of translation mistakes, frees developers to concentrate on functionalities rather than communication/languages, which they don't have to be good at. We don't put translation layer (i18n/ezi18n) until the ext. is finished or almost finished. That also means planning for contexts can be done at that stage, which results in better context organization, and this can be done by different people!

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Monday 28 July 2008 1:01:31 pm

Hi there,

I am very curious what kind of policy you use for defining your contexts, then. I understand the semantic approach - I think it's a good idea - but in practice, it got very messy over time, simply because I couldn't decide/explain what semantic contexts actually exist.
Could you give some real live examples from your end ?

There isn't a consistent policy, yet. It's rather case to case thing, trying to make it as fine as possible. Here's a few hints:
- if there seems to be a practice established, I try to follow it (for example, context names in datatypes (PHP-side))
- if there are rather complex functional modules or module views - I try to group one's translation under one context, sometimes differentiating between interface translations and validation messages, for example,
- I try not to put too many translations into one context - if there are more than 100-200 items in one - that's probably where it could be classified into two or three smaller ones
- if there is 'common phrase' redundancy - I do not get rid of it (for example, sometimes I use the same simple words like "submit", "edit" etc. several times). That's because you never know where there is going to be a change or in which language things will become unequal semantically. That's where one-context-per-file approach is weak actually. If you have one template with two phrases that are homographs in English, one of which is a form label, the other a validation message - they don't have to be homographs in other languages, and with one context you will be unable to cope with that ;(

The redundancy is less then I expected, and actually not a big deal. It is obviously exactly as much as you have code redundancy, which should not be much. If the application changes structure, yes, I have to rebuild the dicts ... if its simply moving a file, search and replace should do.

I believe that search and replace on hundred objects may be pain in the... unless you have some tricks/automation.

Also not that often. In fact, the location of the template / php already *is* pretty semantic, if you use a good layout and naming scheme for your files.

That's true, but I can think of cases where this would lead to crazy context names ;)

This is an interesting topic. I hope some other people share their thoughts.

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Friday 01 August 2008 11:07:04 pm

But as said, I don't use english as the source language, I use tokens (...) I admit, it sounds like a hack. I might as well not use any contexts, and only use tokens, on a small site :-) (...) If you have crazy paths :-) There is a quite similar very interesting discussion: where do you store your templates ?

We are probably going to use tokens in some cases and possibly work out some internal tokenizing system/tool, but still I like the *.ts files, especially for more generic/shared/repeated tools. Once you have your work pushed through this i18n layer, *.ts file is much nicer for translation handing than any tokens I've seen, especially if you comment your translations, if needed.

As far as any conventions go in eZ, we currently try to follow them and any standards and patterns (or at least what seems to be patterns to us). Beside the usual reasons, we're still learning a lot and that helps. The same goes for templates (or maybe I'm not sure what exactly you're asking).

Cheers,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Monday 01 December 2008 5:26:46 pm

A word of warning here.

When parsing templates, ezpublish looks for the translation of a message in

the context + the message + the comment

Yes, the comment is part of the key to find the translation. If you change your comment in the template, or in the dictionary, your translation will be invalid.

It sounds a bit weird to me, but since it is mentioned on issues.ez.no while discussing other bugs, it is apparently known and not a bug ...

$2c,
*-pike

---------------
The class eZContentObjectTreeNode does.

Wednesday 18 March 2009 5:44:40 pm

Hi

I had to think very deep about that one :-) I can't think of an example. I guess you mean something like

      {"Your profile"|i18n('/design/mysite/test')}

could be translated in 'Ihr Profil' or in 'Ihre Profil' - I suppose - but actually, the gender is stuck to 'Profil', so that's not a good example either. Can you give me one example where it is needed to have

      {"Some text"|i18n('/design/mysite/test','female version')}
      {"Some text"|i18n('/design/mysite/test','male version')}

where 'some text' is the same in english ?

just curious,
*-pike

---------------
The class eZContentObjectTreeNode does.