jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldemar Baraldi" <waldemar.bara...@globant.com>
Subject RE: Internationalization of property values
Date Fri, 02 Mar 2007 21:27:23 GMT
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:brdavis@bea.com] 
Sent: Friday, March 02, 2007 5:19 PM
To: users@jackrabbit.apache.org
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" <elephantium@gmail.com> 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:elephantium@gmail.com]
>> Sent: Wednesday, February 28, 2007 11:45 PM
>> To: users@jackrabbit.apache.org
>> 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.


Mime
View raw message