Closed Bug 415242 Opened 17 years ago Closed 16 years ago

Make content ids localizable

Categories

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

Product:
support.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: djst, Assigned: nkoth)

Details

(Whiteboard: tiki_feature, tiki_upstreamed)

Attachments

(1 file)

SQL and PHP script to convert the dynamic content data
1.05 KB, application/x-gzip
Details 
Content IDs (e.g. {content id=2}) should be localizable. All locales could then use the same content ids for things like how to access the Options/Preferences window.
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
May as well make it fall back to (en).
Well. if you simply use the unknown language version as the english version, you will achieve the same goal. Maybe an easy way is simply to make minor changes to the drop-down in the template to hide the "English" option, and reword the "Unknown" option to English for our specific needs.
That sounds good.
Is this already upstreamed?
Whiteboard: tiki_triage
Whiteboard: tiki_triage → tiki_feature
I am looking at the content plugin in the latest Tiki and I'm not even sure it works with "label" as opposed to "id". To recheck.
This upstream would be straightforward, however, I feel some code smell.

Here is the introduction: I never really liked dynamic content. It just feels like an inferior way to reuse content that could be done in a better way using wiki pages and inclusions.

As long as it remained simple, I could live with it. But adding localization seems to be one step too much.

I would propose something similar to what was done for the content templates. Basically, those in tiki were also an inferior way to manage content and SUMO had the great idea of using wiki pages to handle their localization. When I merged back to trunk, I made the template type optional, one of which could be a wiki page.

I would prefer doing the exact same thing for dynamic content rather than adding localization. The dynamic contents would be managed as wiki pages. Some transition would be required for SUMO, but it should be easily scriptable. Free benefits would be revision history, distribution of who can edit the content, ...

Any objections?
Whiteboard: tiki_feature → tiki_feature, tiki_discuss
Using sub-wiki pages instead of dynamic contents is something we've proposed in our 2010 roadmap exactly because of those benefits you mentioned (in addition, localizers would be using the same translation/edit interface for all content). However, changing this on SUMO would involve a LOT of work, so for the time being we're stuck with the content blocks.

If you have any ideas on how we could switch to sub-wikipages right away, this feature wouldn't have to be upstreamed. Otherwise, I don't know what to do about this. Applying the code again after 5.1 upgrade?
I don't see it as such a big change. Contents would still be registered as part of the dynamic content admin and remain accessible through the same plugins.

Only a script would be required to convert them. The script has to:
* Create pages for all content entries. A naming convention would be required initially for the different languages as they all share the same label.
* Attach the pages together.
* Remove non-English content entries.
* Modify the remaining ones to point to the wiki page instead.
About the naming convention for different languages -- actually that's another thing we would like to change in Tiki: the ability to use the same article/wiki page name for different languages. 

Because of our high number of support articles and number of locales, we sometimes find ourselves having to create article translations with far from ideal names, e.g. "JavaScript (fr)" for the French version of the article "JavaScript". We can work around many of them by using more descriptive names (e.g. "What is JavaScript?" or similar), but some languages are very similar, like Danish and Norwegian, so you end up having to include the language code anyway.

Before switching to using sub-pages instead of dynamic content, I would much rather see a solution in place which allowed the same article name in different languages.
There is a technical limitation regarding this due to the design. There are often demands for namespaces, but it's not an easy problem to resolve. There is an option however to hide the naming convention. The page name stripper can be used to hide the language suffix. For example, you could have Introduction^fr and Introduction^en, both displaying as Introduction. I never used it myself, but it's the closest solution to this issue.
That sounds like a reasonable approach if the resulting article title only shows "Introduction" and not "Introduction^fr". 

If we're not going to upstream this fix, we'll have to re-apply this on Tiki 5.1 once we've upgraded...
Unless we could get that script to convert to
sub-articles right away? Would that be a significant effort? I'd rather not
distract you too much with upstreaming and db schema syncing since time is our
enemy here...
Dynamic content can now point to a wiki page and will be handled with multilingual support.

Conversion script remaining.
Archive to be extracted in tiki root before running installer/shell.php. The two files will go under installer/schema/.

Once run by installer/shell.php, the multilingual dynamic contents will be converted to wiki pages and the additional column will be removed.

Content IDs will be different, but most locations should use the labels. If this assumption is incorrect, I can always correct the script.
As I understand it, switching to sub-pages rather than content blocks requires the INCLUDES plugin <http://doc.tikiwiki.org/PluginInclude&structure=Documentation>. Is that a plugin we can install on tikiwiki 1.10 (the version SUMO currently uses), instead of waiting to upgrade SUMO?
The implementation I made in trunk is transparent. You keep using the content plugin, only the content elements will fetch the data from a specified wiki page rather than from the data block. Other than the conversion script provided to create a series of pages and recreate all content elements affected, all content plugins using labels will work without additional changes (yes, content is a plugin rather than a parser hack since 3.0).

You can use the include plugin now, but I don't think it handles the multilingual content. The content plugin was modified to lookup the rendered page's language (or the parser's specified language to be more precise).
So it sounds like we would be better off waiting to update SUMO to the latest version of tikiwiki, correct?
Yes, especially since there should be nothing to do.
Whiteboard: tiki_feature, tiki_discuss → tiki_feature, tiki_upstreamed
Not sure why this was marked as tiki_upstreamed -- is it?
Ok, so we should run that script after we upgrade to Tiki 5.1? It looks good, but just want to verify that we're on the same page here. Thanks.
To be run as part of the database upgrade. All patches in the folder are applied. This is just an additional one for SUMO which converts the old database modification to the new one (wiki pages as dynamic content).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: