Loading...
 
Documentation

Documentation


improving menus

posts: 97

Hi,

With the consent of marc, I just added a "translation how-to" menu entry in the "author resources" menu.

I think this documentation menu, and particularly the "author resources" menu could be improved.

For a start, I noticed two odd entries that could be deleted imho:

  • Edit menu (DocTwoEditors)
    This is already available in the editor menu

  • Submit news (registered)
    The news section seems abandoned and inaccessible via the menus

Also, is it possible to localise somehow the entire menu?

olivier

posts: 400

Hi pianoliv,

I think it's okay to delete Submit news. I didn't see the Edit menu link you are referring to in the author resources menu?

Not sure about localization since the menu item names are considered user input. One idea (but probably not a good one in this case) would be to hide/show menus based on the language shown - ie a new menu module made in French which would show only when French is the site language.

Were there any other things you wanted to change?
Thanks for working on this!
Regards,
lindon


posts: 97

Hi lindon, thanks for your interest.

I removed "Submit news" and "edit menus" (which was the last top level item in the menu).

I also added a link to the revamp proposal.

I think the link to the "editorial board" sould dissapear from the menu as long as the editorial board isn't revived. This link should still be available from the "welcome authors" page.

Maybe the link to "annexes" could also go away, but before I have still to investigate what is up to date there.

I asked marc about the ways to localize the menu, I'm waiting for his answer but I guess your proposal is the right one.

olivier

posts: 2421 Czech Republic

Hi !

You can translate menu items easily when you enable the interactive translation. (Just saying.)

luci

posts: 400

Would agree on the editorial board. Never looked at Annexes before...hmmm...yes, not sure why that would be author resources - good idea to look at that.
Regards,
lindon


posts: 97

luciash d' being 馃:
Thanks for the tip. I just tried this method, but sadly it seems that whatever the site language in use, a menu entry will always send to the english version of a page.
So I guess a complete new localized menu is the better way to go, I'll start building it.

lindon:
Thanks for your inputs. I had a better look at the annexes and there is not much to keep here, most of the infos are pretty outdated or not in the right place.
Since I don't really want to touch the old documentation structure for thoses who are used to it, I am thinking now of creating a new "welcome author" structure which could look as such:

Yesterday, I started merging How To Tag and status tags in the documentation status page.
Documentation Lifecycle could be merged in as well.
About the tiki documentation should be placed somewhere else, I don't know where yet.
The other pages left in the annexes should be moved either in the futur admin guide or other .tiki.org websites.

olivier

posts: 400

pianoliv,

All sound like good ideas. I like the idea of using new and smaller structures for the site. The large main structure on the Doc site is very slow and has a bug that I haven't been able to recreate on other test sites. For instance, you can see on Wiki+Plugin that the list of plugin pages is not in alphabetical order. That's because moving the pages in the structure no longer works and pages sometimes can't be added either - a new structure for wiki plugins would help fix this.

But with new smaller structures we will again have the problem of a default structure. It's not very elegant, but I think PluginParam could be used as a workaround. For instance, I've put the following syntax at the bottom of Wiki+Plugin

{PARAM(name="structure")} {ELSE}{redirect page="Wiki+Plugin&structure=Tiki+User+Guide"}{PARAM}


Now if someone goes to doc.tiki.org/Wiki+Plugin, PluginParam will see that no structure has been specified and redirect the page so that it opens within the Tiki User Guide structure. If the url already specifies a structure, like doc.tiki.org/Wiki+Plugin&structure=Documentation+TOC, then PluginParam will only add a space to the page and let it open in that structure. (I have caching turned off on that page temporarily to show this working)
Regards,
lindon

posts: 97

Hi lindon,

Your trick may not be very elegant but I think it is a nice one because on the other hand it gives us lot of flexibility.
I noticed it could be shortened as such:

{PARAM(name="structure")} {ELSE}{redirect page="{{page}}&structure=Tiki+User+Guide"}{PARAM}

I could not make it any simpler (using plugin aliases or dynamic content), maybe would you know how and if it is likable?

Should I start copying this code to wiki pages?

Also, I could not create a new structure with the existing welcome authors page as the mother page. I don't want to delete this page to proceed, what should I do?

oliv'

posts: 400

I tried using Dynamic Variable but I couldn't get it to work - the variable seems to be read literally when part of a plugin parameter. (I created %userguide% on the doc site with the value: &structure=Tiki+User+Guide).

I'm fine with you proceeding with the use of the param plugin - seems like the best solution we have for now.
Regards,
lindon

posts: 2421 Czech Republic

pianoliv: sure, it would need the preference (which i do not remember how it is called exactly now) "display/switch the site language preferred by user by the language of the page" enabled and the page must be translated to the language and indicated it is translation of the english one...
then if that is set, it will automatically show in the correct language and fall back to english one if translated page in the specified language does not exist.

luci

PS: sorry for late reply

posts: 97
I can't find what and where is this option, do you remember its name?
posts: 2421 Czech Republic

Administration > i18n > Show pages in user's preferred language

Administration > i18n > Users can change site language

and

Administration > i18n > Sync Language for Page and Site

posts: 97

Thanks for the pointer lucy
I activated "Show pages in user's preferred language" and it behave as expected.
"Sync Language for Page and Site" doesn't seem necessary, also I like to be able to switch language only for the page.

So I'll destroy my new french menu and translate the english one, it's going to be easier to maintain the menu in all languages this way.

olivier

posts: 2421 Czech Republic

Just one little more hint for translating the menus:

I recommend to use custom strings for the menu items names translation, something like this for example:

mi_Features
mi_Download
mi_...

This way you can safely translate the items without interferring with the default translation strings used elsewhere in Tiki.

You will need to "translate" the strings to default English of course too.

luci

PS: yes, it is luci with "i", not "y" ;-)

posts: 97

Good call, I'll change that some day.

And please pardon me, my English isn't so good :-)

oliv'



posts: 97
Also, the "author ressource" first level menu entry is now a link to the "welcome authors" page.

posts: 97
Update: There is now a French version of the menu.


posts: 97

Update:
I created a dedicated structure for author resources, using a few tricks:

  • The structure's mother page is HomePage Author and has an "HomePage" alias. It redirects to the doc.t.o homepage
  • There is only one first level page on this structure (author resources). This allows to display the structure in the left hand column menu as desired (since all first level pages are displayed there and we only want one)
  • A few pages in the structure redirect to other pages on tiki.org. This allows to display thoses pages in the structure and the menu-structure.
  • I replaced the menu module in the left hand column by a custom module which contains this smarty code:
    {menu id=43 decorations=n notitle=y}
    {if $group neq ''}
    {menu structureId="HomePage Author"}
    {/if}

    As you can see, the last menu entry (author resources) is now an automated menu-structure, and is only displayed to non-anonymous (anonymous equal empty $group variable)
    The advantage of this custom module over two separate modules (a menu module and a menu-structure module) is that it is foldable.

Now, if you like this method, it could also be applied to other menu entries, such as the new guides. Then, all pages will be displayed in the menu. You can have a look at http://www.linuxmao.org to see these tricks in action on all structures.

olivier


posts: 400

Looks nice. Assuming there are not many redirects, I would be okay with using this for the other guides since the fold-out menus are nice. Not sure if it's really an issue, but seems like having a number of redirects could get confusing and be a little inefficient.
Thanks again for all the work on this!
lindon


Page: 1/2  [Next]