[opencms-dev] Multilingual NavText

Thu Oct 27 11:49:20 CEST 2011

Hi Paul,

thanks again for the suggestion.

I'd just like to keep you updated:

We've now settled to build our own navigation implementation using
structured content as well.
For editing the file I copied the CmsXmlContentEditor, changed its layout
and added functionality for easier editing (collapse/expand, copy/paste
element, etc.).

Thanks again for your help and inspirations. :)

Cheers,

Thomas

2011/10/15 Paul-Inge Flakstad <flakstad at npolar.no>

> Hi Thomas,****
>
> ** **
>
> I really don’t know the sitemap editor very well, as I’m not using it.****
>
> ** **
>
> As for the single structured content file for navigation:****
>
> Yes, this “navigation definition” file stores the navigation in different
> locales, exactly like with other types of (structured) content in OpenCms.
> ****
>
> Yes, it is completely manual (unless you add some automated listing or
> something, which I’ve done in special cases), with independent content (when
> I say “content” I mean “the links that make up the navigation tree”) for
> each locale.****
>
> ** **
>
> I did use a custom content type – the structured content type I created for
> the “navigation definition” – but no special widgets, only the VFS file
> widget. (A navigation is quite simple, it’s really just a bunch of links in
> a tree structure. And each link consist of just 2 things: a target URI and a
> navigation text. So the only complexity is in how you create the tree.) **
> **
>
> ** **
>
> The majority of the hours spent developing this module went into the class
> library, which allows me to access the menu as an object. (The menu object
> is really just a tree structure which is built by reading the “navigation
> definition” file). I would strongly encourage this approach instead of just
> using JSPs (like I did at first). It gave me a bunch of benefits.
> Programming is a breeze – with just a few lines of code I can easily get the
> menu or parts of it, get the breadcrumb menu, determine what menu item is
> the “current” one, and so on. Everything is easy, and just works very well!
> (If I may say so myself :)****
>
> ** **
>
> To illustrate, the actual code could look as simple as something like this:
> ****
>
> MenuFactory mf = new MenuFactory(pageContext, request, response); //
> MenuFactory extends CmsJspXmlContentBean****
>
> Menu menu = mf.createFromXml(“my-menu-definition-file”);****
>
> boolean menuContainsRequestPage =
> menu.setCurrent(mf.getRequestContext().getUri());****
>
> out.print(menu.getHtml());****
>
> ** **
>
> The .xsd is actually several nested .xsd’s (the number of .xsd’s will
> depend on the max. depth of your navigation), but each one looks pretty much
> the same. Each level (except the level at max. depth) consists of:****
>
> **1.       **A target URI and a navigation text****
>
> **2.       **An optional list of sub-elements, where each item in the list
> is also just a target URI and a navigation text****
>
> ** **
>
> Of course, there are some drawbacks to my solution... I have been unable to
> create an .xsd that allows for an arbitrary menu depth. Consequently, the
> menu depth is finite. (Adjusting the depth is easy, but I’ve settled for a
> max. depth of 4, as I’ve found that this depth has been sufficient on all of
> my sites. In terms of usability I’m also confident that shallow menus are
> far better than deep ones – in nearly all cases.)****
>
> ** **
>
> There is no collapse/expand functionality when editing, and reloading the
> edit view, e.g. when you add/move/delete items, will grow slower
> proportional to the size of your navigation. (However, if this becomes a
> serious problem, it can be avoided by splitting the navigation into several
> files instead of containing the entire definition in a single file.)****
>
> ** **
>
> Sounds scary, I know – but that being said, I’ve got some quite big
> navigation files on a couple of sites  (see for example
> http://www.npolar.no/en/ - the entire navigation there is one file), and I
> hardly consider the reloads a problem. This is in part because navigation
> files are rarely edited once they are finished the first time. Those few
> times when I do any editing, it’s usually just a case of
> adding/moving/deleting one or two items, and because it is “just a quick
> edit”, the slightly slow reloads are not at all as annoying as one might
> think.****
>
> ** **
>
> As for customizing the “Edit navigation” option, I can’t give an exact
> answer, but I’d start by examining the handler JSP. I don’t know how easy it
> is to create custom dialogs, only that it should be possible. (Alkacon has
> custom dialogs for some resource types, for example).****
>
> ** **
>
> It would be great to contribute my alternative navigation module at some
> time, but currently I’m unable to. :(****
>
> ** **
>
> Anyway, hope this helps you.****
>
> ** **
>
> Cheers,****
>
> Paul****
>
> ** **
>
> ** **
>
> *From:* opencms-dev-bounces at opencms.org [mailto:
> opencms-dev-bounces at opencms.org] *On Behalf Of *Thomas Göttlich
> *Sent:* 14. oktober 2011 16:45
>
> *To:* The OpenCms mailing list
> *Subject:* Re: [opencms-dev] Multilingual NavText****
>
> ** **
>
> Hi Paul, hi Christoph,
>
> thanks for the information.
>
> Is it possible to use the sitemap editor from the workplace as well or only
> using ADE?
>
> @Paul ah, thanks for the explanation. I didn't think of a single XML-file
> describing the entire navigation.
> Yes, that might be a quite usable approach.
> Did you store the navigation per language then?
> If so, you'd still need to manually update the navigation in all languages
> when you have changes, wouldn't you? (I mean when creating a new language
> the content of the default language is copied, but after that it'll be
> independent, right?)
>
> I think I'll strongly consider that approach as well, since that would also
> enable kind of wysiwyg navigation editing (move up, down etc.).
> Would you mind giving an example of how your xsd looks like?
> Did you use any special widgets or custom content types?
>
> Besides of that, is there a custom editor/option/widget that would allow to
> collapse subtrees when editing the xml-content for the navigation?
> The navigation trees in the XML might become quite big with several levels,
> so it would be quite helpful if that was possible somehow (to reduce
> scrolling etc.).
>
>
> Btw, how would I customize the "edit navigation" option?
>
> Thanks for your help so far and the really good suggestions.
>
> Cheers,
>
> Thomas****
>
> 2011/10/14 Paul-Inge Flakstad <flakstad at npolar.no>****
>
> Hi Thomas,****
>
>  ****
>
> See my comments below.****
>
>  ****
>
> Hi Paul,
>
> well, structured content can contain multiple languages so I'd say that
> also an intended possibility in OpenCMS. It's just the navigation that
> doesn't support that.****
>
> Content in multiple languages is indeed an intended possibility, but the
> standard way to _*handle*_ content in multiple languages is by employing
> siblings. (Relying heavily upon the fact that siblings do not necessarily
> share their set of properties. Furthermore, as you know, the standard
> OpenCms navigation is partly property-based.)****
>
> We also have parts of our site that define the navigation inside the xml
> content. That, however, makes it harder to view the navigation in the
> workplace explorer, since you'd then have to open the resource file. Ok,
> editing navigation in the workplace explorer is still suboptimal - you can't
> see the navpos for example - but it's still a start and AFAIK you don't have
> the new sitemap editor in the workplace, do you?****
>
> I’ve created 20+ sites, all with a structured content-based navigation, and
> most with the entire navigation tree defined in a single file. Many editors
> have been involved, and this implementation has been easily understood by
> them. Given that the navigation tree is visible to them when editing the
> file, the whole thing is actually quite intuitive. (Of course, I do not get
> to use the new sitemap editor, but that’s hardly a problem. Bottom line is
> the standard OpenCms navigation solution does not work for me, and the
> structured content solution is a good substitute.)****
>
>
>
> I'll think about the property-per-language approach, but that has the
> disadvantage that standard edit options like "edit navigation" wouldn't
> support that.****
>
> It is possible to customize the edit option so that it would handle your
> custom solution.****
>
> Best regards,****
>
> Paul****
>
> 2011/10/14 Paul-Inge Flakstad <flakstad at npolar.no>****
>
> Hi Thomas,****
>
>  ****
>
> First of all, I don’t think you’re asking a commonly asked question. The
> “default” way to handle multiple languages in OpenCms is by employing
> siblings. Since you’re avoiding this (I don’t get why, it’s a pretty neat
> solution), you’re also straying from the way OpenCms was intended to work.
> With this in mind, I wouldn’t expect to find a quick fix anywhere. You’re at
> a point where you’ll have to create a custom implementation. ****
>
>  ****
>
> While your proposed solutions would work, they do raise the bar for the
> editors, and errors are likely to occur.****
>
>  ****
>
> A couple of other suggestions:****
>
> 1.       Define one navtext property for each language. (Basically the
> same as using the default property, but this way you’ll free the editors
> from the syntax requirement.)****
>
> 2.       Make your own navigation system – structured content works well
> for this. (I would go for this. It is like your properties file alternative,
> but easier to maintain. I have successfully implemented such a system on my
> sites, because I wanted a navigation that was independent from the folder
> structure. It works like a charm. :)****
>
>  ****
>
> HTH. ****
>
>  ****
>
> Best regards,****
>
> Paul****
>
>  ****
>
> *From:* opencms-dev-bounces at opencms.org [mailto:
> opencms-dev-bounces at opencms.org] *On Behalf Of *Thomas Göttlich
> *Sent:* 14. oktober 2011 11:30
> *To:* The OpenCms mailing list
> *Subject:* [opencms-dev] Multilingual NavText****
>
>  ****
>
> Hi,
>
> I know this is a commonly asked question but since I couldn't find anything
> helpful in the wiki or using google yet, I'll ask my question here:
>
> How can I maintain a folder's navtext property in a multilingual way?
>
> We currently have a site that consists of one tree and structured content
> containing mutliple languages.
> Our templates use a fallback mechanism to retrieve content in the default
> language (English) if there's no content for the requested language (e.g.
> German).
> This works on a per-field basis, i.e. you could, for example, set some
> images in the default language only and just translate the text in the other
> supported languages.
>
> Because of this, and since it is a much cleaner approach IMHO, we don't
> want to fiddle around with different structures in multiple languages (i.e.
> no siblings!).
>
> All worked fine so far, since we didn't use the OpenCMS navigation
> facilities yet.
>
> However, now we need to employ them and thus there's the problem of how to
> translate the navtext property.
>
> Right now I could think of two ways, both of which don't fully satisfy me:
>
> 1. Store a key in the navtext and in the template access a properties file.
> That would require the user to maintain an additional file and keep it in
> sync with the keys.
>
> 2. Directly store the translations in the navtext, i.e. like this: "en=Some
> Folder,de=Irgendein Ordner,nl=Een map,es=Cualquier directorio,zh=某一个文件夹"
> etc.
> Then I'd have to split the navtext in the template and extract the correct
> language. The problem with this is that it's quite fragile since the user
> would need to enter the translations in the correct format, i.e. <language
> code>=<translation>,<language code>=<translation>, ... . This might be error
> prone.
>
> Any more ideas?
>
> Thanks in advance,
>
> Thomas****
>
>
>
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev****
>
>  ****
>
>
>
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev****
>
> ** **
>
>
> _______________________________________________
> This mail is sent to you from the opencms-dev mailing list
> To change your list options, or to unsubscribe from the list, please visit
> http://lists.opencms.org/mailman/listinfo/opencms-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20111027/b19538ca/attachment.htm>