{quote}
If you have more than one objects that must be translated on a page, you
cannot use this function, because, as you see, there is no "number"
parameter. However, you can write you own code that iterates over all
objects.
{/quote}
Generally, it is recommended to have one main object per page. It is not a
must, the final decision is yours, and it depends on the application
profile.
Sergiu
On 1/9/07, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> wrote:
 Hi,
 Internally, a document has only one principal version, the one in the
 original language. Translations are just variants of that original document.
 Objects are attached to a document, meaning that an object is bound to the
 original document. This way you can't have (for the moment) objects attached
 to a translation. This is bound to change in 1.1 (or later).
 However, you can simulate this by using (indeed) a language property.
 In detail:
 1. You must add a StringProperty for each class you would like to be
 translatable, named "lang" (or any other name you like)
 2. Replace doc.getObject("MyClass") with doc.getObject("MyClass",
"lang",
 $context.language[, true]). This return an object with the "lang" property
 set to the current language. Of course, you can replace $context.language
 with a specific language. The optional true parameter stands for failover,
 meaning that if an object with the requested language was not found, try
 again without the language filter.
 You cannot automatically translate objects with the current skin. If you
 are interested, I can give you the code for a panel and a page that can be
 used for this.
 If you have more than one objects that must be translated on a page, you
 cannot use this function, because, as you see, there is no "number"
 parameter. However, you can write you own code that iterates over all
 objects.
 On 1/9/07, petteri.karttunen(a)kuopionkonservatorio.fi
<petteri.karttunen(a)kuopionkonservatorio.fi>
 wrote:
  Yes, the wizard works correctly as far as I can
see. The problem is
 perhaps more obvious with tagging for example (default XWiki.TagClass)
 ;  if you want to tag the content of the same page differently depending on
 the page translation you have to add a TagClass instance for every
 translation and somehow bind them to translation in question(?)
 So is there a reason why the object's properties should be language
 independent? These are fundamental questions for me when planning the
 structure of my xwiki-based translation portal by no means impassable
 obstacles. Before fixing the custom class structure I would anyway very much
 like to hear your thoughts and developers' plans if the logic is going to
 stay this way in future releases.
 Thanks!
 Petteri
 --
 You receive this message as a subscriber of the
 xwiki-users(a)objectweb.org mailing list.
 To unsubscribe: mailto: xwiki-users-unsubscribe(a)objectweb.org
 For general help: mailto:sympa@objectweb.org?subject=help
 ObjectWeb mailing lists service home page: 
http://www.objectweb.org/wws