Hi, Given the changes below, I think, we should not release the i18n module yet with the initial Sling release. Instead we should carefully build these changes into the module and release as soon as we are ready.
Please, create an issue for these changes. More comments inline. Am Donnerstag, den 05.06.2008, 12:41 +0200 schrieb Alexander Klimetschek: > 1) I think the name "sling:Language" is misleading. I suggest to name > it "sling:MessageBundle", because it is a container for messages, not > a language. +1 > 2) Not sure for which use cases the sling:basename propert is needed. This is to support getting a subset of all messages and is comparable in some sense to the basename argument of the ResourceBundle.getResourceBundle(String, Locale) method. It is used to implement the SlingHttpServletRequest.getResourceBundle(String, Locale) method. > 3) sling:MessageBundle would only contain sling:Messages - we don't > want to mix it with other content if this structure is typically > auto-generated (eg. XLIFF importer) +1 but have sling:MessageBundle extend nt:hierarchyNode to be able to place such bundles below 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) Not sure about the nt:hierarchyNode inheritance for > sling:Message(Entry) - do we need it? If sling:Message are only required (and supported) to be children of a sling:MessageBundle node, I am fine with removing that. Instead the sling:MessageBundle should extend nt:hierarchyNode (see above). > > 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.) Not sure, whether this is implementable. If you could provide me with good queries to find messages by key, I might get convinced. In priniciple, I think it is not a bad idea. But it must be implementable ;-) > > 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 +1 if (6) proves possible. > > Proposed new i18n Nodetypes > ======================== > > Example 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." > > Nodetypes: > > [sling:MessageBundle] > mix:language > + * (sling:Message) As said above, this would be: [sling:MessageBundle] > nt:hierarchyNode, mix:language - basename (string) + * (sling:Message) > > [sling:Message] > - sling:key (string) > - sling:message (undefined) > > All in all this sounds reasonable IMHO. Regards Felix
