Thanks Bryan, I will follow the same approach. Thanks all by the way. Waldemar
-----Original Message----- From: Bryan Davis [mailto:[EMAIL PROTECTED] Sent: Friday, March 02, 2007 6:39 PM To: [email protected] Subject: Re: Internationalization of property values We just added the JSR-283 node types as custom node types in our implementation... Eventually we will remove the custom type creation when they are supplied by Jackrabbit (that is the plan anyway). Bryan. On 3/2/07 1:27 PM, "Waldemar Baraldi" <[EMAIL PROTECTED]> wrote: > Bryan, thanks for your answer. I guess I cannot count on it to be > implemented already. It's an elegant solution that I may implement by > myself so far, right? > > > -----Original Message----- > From: Bryan Davis [mailto:[EMAIL PROTECTED] > Sent: Friday, March 02, 2007 5:19 PM > To: [email protected] > Subject: Re: Internationalization of property values > > JSR 283 speaks directly to this... From the latest jsr-283.doc: > >> 4.11.1 Internationalization >> The mix:lang mixin node type defines a single string property, >> jcr:lang, that can be used to specify the natural language in which >> the content of a node is expressed. The jcr:lang property is based on >> the standard XML attribute, xml:lang. >> [mix:lang] mixin >> - jcr:lang (string) mandatory >> >> This node type is optional. >> The format of the jcr:lang property should be the same as that of the >> xml:lang attribute, that is, a language code as defined in RFC 3066 >> (see http://www.ietf.org/rfc/rfc3066.txt), examples include "en" > (English), "en-US" >> (United States English), "de" (German) and "de-CH" (Swiss German). >> >> 4.11.2 Natural Language Text >> The following predefined node type can be used for storing natural >> language text. >> [nt:naturalText] >> - jcr:text (string) >> - jcr:messageId (string) >> >> This node type is optional. >> Nodes of type nt:naturalText are intended to be used in place of >> simple string properties when the content being stored is known to be >> text in a natural language (or a message ID representing such a text). >> The text can be represented within the node either directly as in the >> jcr:text property or indirectly using the jcr:messageId property, >> that the application would then use to look up the appropriate >> literal text. Note that nodes that use the literal jcr:text property >> might also be assigned the mix:lang mixin type, which would provide >> information > as to the language of the text. > > > > On 3/2/07 9:55 AM, "Brian Thompson" <[EMAIL PROTECTED]> wrote: > >> Off the top of my head, I might encode the data as an XML string with >> a language declaration as the first element. Something like >> >> XML declaration >> <lang="de"><data>(title data in German here)</data></lang> >> >> or something similar. >> >> -Brian >> >> >> >> Waldemar Baraldi wrote: >>> Thanks guys, I think I will implement something like Brian's option >>> 2 (very similar to Tobia's suggestion). >>> >>> By the way, Brian, how would you recognize to which language a value >>> in the multi-valued property corresponds in Option 3? I ask because >>> I haven't discarded it completely :-). >>> >>> Regards, >>> >>> Waldemar >>> >>> -----Original Message----- >>> From: Brian Thompson [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, February 28, 2007 11:45 PM >>> To: [email protected] >>> Subject: Re: Internationalization of property values >>> >>> The way I see it, you have three options: >>> >>> Option 1: Separate nodes, one for each language. If you maintain >>> separate workspaces (again, one for each language), you can create >>> the initial movie node and clone() it to the other language workspaces. >>> Each language-version of the movie node will then share the same >>> UUID, making lookups easier (just log in to the appropriate >>> workspace when you're looking for a particular language's version of movie data). >>> >>> If you don't go with multiple workspaces, it gets trickier - you >>> could build a logical linked list with node references, but that >>> seems harder to deal with. >>> >>> Option 2: One movie node, multiple child nodes for languages. >>> Create all the child nodes as the same type (movie:properties or >>> something similar), and put your properties on the child nodes. >>> >>> Option 3: Make each property multi-valued. This keeps all language >>> versions of each property all in the same place, simplifying >>> insertion and retrieval. The downside is that, every time you >>> retrieve any property, you are forced to retrieve all language >>> versions > of it. >>> >>> Hope this helps, >>> >>> -Brian >>> >>> >>> >>> Waldemar Baraldi wrote: >>>> Hi all, >>>> >>>> I want my nodes to have internationalizable properties. Let's say a >>>> node of type movie has a string property called 'title', I want to >>>> set the value to that property in different languages. I don't want >>>> to have multiple nodes (for the same movie) just to maintain > translations. >>>> I believe the JCR standard doesn't support something like that. I'm >>>> thinking about how to implement something like this. >>>> >>>> Any help, ideas or shared experience will be greatly welcome. >>>> >>>> Thanks in advance. >>>> >>>> Waldemar >>> >>> > > ______________________________________________________________________ > _ > Notice: This email message, together with any attachments, may > contain information of BEA Systems, Inc., its subsidiaries and > affiliated entities, that may be confidential, proprietary, > copyrighted and/or legally privileged, and is intended solely for the > use of the individual or entity named in this message. If you are not > the intended recipient, and have received this message in error, > please immediately return this by email and then delete it. > _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
