>>I see the solution, it solves the problem as long as the value of the
>>output, meaning also the key of the i18n isn't a whole sentence, which
>>offcourse ends out being my case. ;-) , I think I'll manage to cut my
>>sentences short, so this should work for me thanks.
>>
>>
>
> Why couldn't it work with a whole sentence? A key is a key, whatever its
> length. Or am I missing something?
you're probably right, I was thinking of all sorts of characters that might
be a problem, I haven't tested yet , but will keep yu informed
>>But out of curiosity, I don't have the knowledge to weigh how much work it
>>would take to allow an fd:selection-list tag in the repeater on an output
>>widget definition?? For the mapping to happen just like in a field
>>selection-list and then no i18n-ation pb :-)
>>
>>
>
> Sorry, but I don't understand "fd:selection-list tag in the repeater on
> an output widget definition". Can you provide an example on how you
> would like this to be written?
sorry, I hope this is a bit more clear. it can actually work without talking
about repeaters. This could simply be an output widget mapped on a
selection list, meaning if the output widget has a fd:selection-list
specified in that case the value of the output will be pulled out of that
selection list, therefore dealing with translation.
<fd:output id="size">
<fd:datatype base="string"/>
<fd:selection-list src="list.xml">
</fd:output>
lets say in my data xml file, my size output widget is bound to
<size>5</size>and in my selection list file "list.xml"
amongst other items i would have
<item value="5">
<i18n:text key="text5">King Size Bed</i18n:text>
</item>
where as it now, all has to be done in a custom bind.
meaning that for our repeater scenario every row (with an output) would be
automaticaly translated , and the bind would be as simple as a normal
repeater, wouldn't it ?
Hope this is more clear :)
Regards
Tibor
