[opencms-dev] Multilingual NavText

[Paul-Inge Flakstad]

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<mailto: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<mailto: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> [mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20111015/c079514f/attachment.htm>