406764 - Friendly names for dynamic content in TikiWiki

Status: VERIFIED FIXED

(support.mozilla.org :: General, enhancement)

Description

[David Tenser [:djst]]

Currently, you can use "macros" in TikiWiki which allows you to type e.g. {content id=2} in a wiki document, which will insert a block of text. We currently use this for information we use in many documents, such as how to exit Firefox.

However, it's hard to remember which number is assigned to which macro. It would be much easier if you could type e.g. {content id=exit_firefox}, {content id=safe_mode}, etc.

Is there an RFE for this in TikiWiki?

Comment 1

[Majken Connor [:Kensie]]

I think fixing this is going to be a huge benefit to localizers, if I understand correctly, it will help solve the issue of not being able to pull from .dtd files. Should we target this towards the localization milestone?

Comment 2

[dynamis (Tomoya ASAI)]

With this enhancement we can do two things:

 (A) We can use this like .dtd used in html files
For example entities used in html like &pref.pluralCaps; will be
{content id=pref.pluralCaps} in SUMO wiki.
UI label will continue changing before the final release and this is needed to
keep consistency.

 (B) We can use simple expression for OS dependent terms
For example we can write like "{content id=options}" instead of current very
complex expression like:
  "{DIV(class=>noMac,type=>span)}options{DIV}
   {DIV(class=>mac,type=>span)}preferences{DIV}"
Some UI labels of Firefox are different in OSs and we need to use expression
like above many times. But current expression is very complex and not easy to
maintain.
Without simple expression it's difficult to write OS dependent terms properly.

Especially in our locale (Japanese: ja for win/unix and ja-JP-mac for mac),
we use many terms which are same in English OSs but different in Japanese OSs
and difficult (possible but very tired) to maintain without simple expression.


Sumo is wiki and key point of wiki is *easy* to edit by anyone isn't it?
It's difficult (and tired) to keep quality (consistency and OS dependency) of
our help contents on the wiki system without this feature.
Not required to be implemented right now but please please implement this.
I'm sure this will make our localization work much easier and we will be able to
write higher quality documents.


note:
Current dynamic content of TikiWiki isn't language sensitive and we may have to
write like {content id=en.pref.pluralCaps} or {content id=ja.pref.pluralCaps}

Comment 3

[David Tenser [:djst]]

Thanks for your comments, dynamis. We discussed this bug recently and it sounds like an approach for both localization and simplification of complex wiki text blocks that would make a lot of sense. 

This particular bug is about friendly names for the content id's, but the next step would be to make it localizable. Nelson, what's your take on this bug?

Comment 4

[Nelson Ko [:nkoth]]

I could do this bug next week, but not to make it fully localizable. Meaning you would have to write like:

{content id=en.pref.pluralCaps} or {content id=ja.pref.pluralCaps}

Comment 5

[Nelson Ko [:nkoth]]

I have this somewhat done waiting upon some db schema updates (in conjunction with bug 415242). The behavior is that you can have either refer to a particular content by:

{content id=3) where the exact content is returned, regardless of language.

or {content label=xxxxxxx} where it will only be shown if the language of the page matches the language of the dynamic content. If dynamic content does not exist in that language, it will fall back to the block for the "unknown" language, if available.

This form should be used for blocks. For dtd like terms, the dynamic variable system provided through bug 415243 is better.

Comment 6

[Chris Ilias [:cilias]]

v
Sweeeett!