[jira] [Updated] (SLING-517) Improve i18n node types

["Konrad Windszus (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Konrad Windszus updated SLING-517:
----------------------------------
    Component/s: i18n

> Improve i18n node types
> -----------------------
>
>                 Key: SLING-517
>                 URL: https://issues.apache.org/jira/browse/SLING-517
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions, i18n
>    Affects Versions: I18n 2.0.2
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler
>             Fix For: I18n 2.0.2
>
>
> As discussed on the mailing list http://markmail.org/message/dobbllzzimgtwssg, the current node types in the i18n bundle should be improved regarding naming and a more efficient and human-readable content structure.
> 1) Rename node type "sling:Language" to "sling:MessageBundle", because it is a container for messages, not a language.
> 2) "sling:MessageBundle" only contains "sling:Message"s - we don't want to mix it with other content if this structure is typically auto-generated (eg. XLIFF importer)
> 3) "sling:MessageBundle" extends nt:hierarchyNode to be able to place it inside a nt:folder.
> 4) "sling:Message" can be a node type, I don't see the case where one wants to mix it with an existing node type structure and needs a mixin. "sling:MessageEntry" can be removed then.
> 5) "sling:Message" does not need to inherit from nt:hierarchyNode anymore (it will only be use inside sling:MessageBundle, which can be put into an nt:folder)
> 6) The sling:key should be optional and only be used if the actual key (which would typically be the original, eg. english, source string) is not a valid JCR name. Otherwise the node name should be the key (no need for generating message1, message2, etc.)
> 7) If the key is not valid for the jcr name, we generate a valid name based on the key, to make the node structure more browsable.
> Here is a pseudo algorithm for generating the key:
>   input: node name
>   esc = cut off 50 char from key
>   esc = escape esc (using org.apache.jackrabbit.util.Text.escapeIllegalJcrChars())
>   if escaped == original key => put in node name
>   else => put in sling:key property, use
>   ensure unique name! append number
> 8) JcrResourceBundle must be changed that it always loads all entries from the sling:MessageBundle into a hashmap (as it does now already if one calls ResourceBundle.getKeys()). This way it knows the correct keys which are either in the node name or in the sling:key property because it loads them properly upon intial loading. The single key query that is done in ResourceBundle.handleGetObject() will be changed to access the hashmap only.
> The latter change should improve performance due to in-memory caching, albeit the first call to getObject() or getString() will be a bit slower.
> New node types
> =============
> [sling:MessageBundle] > nt:hierarchyNode, mix:language
>   - basename (string)
>   + * (sling:Message)
> [sling:Message] > nt:base
>  - sling:key (string)
>  - sling:message (undefined)
> Example (new) node tree
> ====================
> /libs/languages
>    + Deutsch (sling:MessageBundle)
>         - jcr:language = de-ch
>         + Ok (sling:Message)
>              - sling:message = "'sch Ok"
>         + Lorem_Ipsum_001 (sling:Message)
>              - sling:key = "Lorem Ipsum is simply [...]"
>              - sling:message = "Mir doch egal."



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)