eZ Community » Forums » General » translating options in Selection...
expandshrink

translating options in Selection attribute - bug?

translating options in Selection attribute - bug?

Wednesday 30 July 2008 8:43:55 pm - 12 replies

Hi,

I just noticed following issue:

I have a class with Selection attribute which is information collector.

When I translate this class to different language and change for example attribute name - it's properly applied. But if I translate option of this attribute - all translations of this option have value of translation which I entered as last one.

So for example, attribute Selection in eng-GB has option: 'good morning'

Now, I translate whole class and attribute to ger-DE and change this option to become: 'guten tag'

Result: both versions of this class (eng-GB and ger-DE) have same option 'guten tag' in this Selection attribute.

I discovered this on 4.0.1rc1 and noticed same behavior on 4.0 - are you aware of this problem and can someone confirm it?

Michal

Thursday 31 July 2008 12:25:27 am

Its not a bug, eZ Publish doesn't currently support translation on class attribute values (default values + selection values) only name of the attribute and name of the class.

A discussion on class enhancements:
http://ez.no/developer/forum/setu.../content_class_attribute_description

Thursday 31 July 2008 12:35:01 am

that's not pretty suspicious.gif Emoticon

any plans to implements this? I'll have to workaround it somehow...

Thursday 31 July 2008 6:39:51 am

Michal,

It is definitely possible to implement with some extension-writing skills. I have a custom extension made for that (for checkboxes only, not all selection modes). I'm not sure if I will be able to share that, but the idea goes like this:

- there is an extra tab and interfaces for managing 1:n->1:n db model (category set -> category -> category translation); those make it possible to create sets that contain any number of identifier-named categories that can be assigned translations in any language available
- there is a special i18n operator for figuring out whether there is a translation for a category in this particular language, or if identifier should be used as a last resort.
- there is a datatype, for which you define which category set to use during class definition. It also introduces one more db table for actually reflecting object-category n:n relation.

As a result, categories are translated automatically (if the translations had been prepared), but again - the attribute itself is not translatable - it will have the exact same selection for each document translation (which was what we needed).

One good thing about this model is that we can categorize multiple class objects in this way, using one category set.

I'll see if we're able to share the extension.

Thursday 31 July 2008 9:34:36 am

Thanks for hints, maybe it's time to start digging bit more into eZ internals blunk.gif Emoticon

Thursday 31 July 2008 9:41:42 am

Just for the reference: http://issues.ez.no/13248 : ezselection datatype translation not possible

Thursday 19 March 2009 11:32:50 pm

Now that 4.1 is done, can eZ Systems PLEASE put some resources into implementing translation of selection values.

Customers are not happy about this issue at all.

Friday 20 March 2009 8:42:06 am

We probably will.

Modified on Friday 20 March 2009 8:42:38 am by André R

Monday 30 March 2009 8:37:06 am

Hi,

I hope eZ can put some works on this issue. This is just terribly important to claim that eZ is truly multilingual.

Wednesday 29 April 2009 4:16:29 pm

Yes, this is really important...

just opened a enhancement ticket (last one referring to this was some years old...)

By the way, i solved this for a client using an override of ezselection.tpl and changing:

{$Options.item.name|wash( xhtml )}

to

{$Options.item.name|i18n("example/options")|wash( xhtml )}

Of course very manual (for example when updating or adding options ts file has to be updated in all languages) but it works... happy.gif Emoticon

Modified on Wednesday 29 April 2009 4:17:24 pm by Andreas Kaiser

Wednesday 07 April 2010 2:15:14 pm

Since this topic popped up again on twitter today, here is current progress:

What is left is for someone to complete ezselection2 with support for data_text_i18n and eventually upgrade script for ezselection -> ezselection2 so it can be included in eZ Publish and replace ezselection.

Modified on Wednesday 07 April 2010 2:16:02 pm by André R

Thursday 29 April 2010 3:58:05 pm

Just to let you know that it is very important to be able to translate selection datatypes - since this is not possible, we have not yet bothered to use class translations...... And we have to resolve to some pretty unlogical work-arounds in order to translate selections....

(I cannot quite figure out from this very short description how this low level support works in 4.3.....)

Friday 20 August 2010 2:05:07 pm

Since this topic popped up again on twitter today, here is current progress:

What is left is for someone to complete ezselection2 with support for data_text_i18n and eventually upgrade script for ezselection -> ezselection2 so it can be included in eZ Publish and replace ezselection.

André, as far as I understood, the role of data_text_i18n is to store translatable "default values" (default ezstring value, default ezinteger value, etc), is that it ?

If the answer is yes, on a pure practical point of view, does anyone really need to support it in ezselection2 ?

Because if ezselection2 only lacks this (but DOES support multilingual options on the go) and an update script, I would consider it more beta than alpha for my personal use...

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from