jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Davis <brda...@bea.com>
Subject Re: Internationalization of property values
Date Fri, 02 Mar 2007 20:18:33 GMT
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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message