Quote:

Hmmm...
Good point, right.

have to think about this. At the Heffterhof Website (that's the site I've mentioned) there is just one person in chief of editing content, the community-functionality was turned off (but will become active again, as soon as the customer's got all of his content on line). That makes things quite easy....

Cheers! Christian Jarolim

Hi svaha,

thanks for the snippet.

Looks cool and If I may I'd be happy to use your code in one of my upcoming projects, too.

I also will have to consider, how to support more than one editors (i.e., for each language one, maybe for each topic another one). They should be prompted automaticly, when there is a change in a language to adapt it to their's. And some 'editor in chief' function should be there, too. Mixing a project management tool with an CVS and XOOPS... But this might get a bit too complicated from where we are now.


Thanks anyways!



Christian Jarolim
--
//jarolim.com
//The Label on Line

i would like to sugest to look at another CMS which seem to be able to handle multiple languages in 2 ways.
one - as separate trees for each language and
second as - one tree where each page would have an option of being translated to another language
http://typo3.org/1220.0.html

i am more interested in second concept, but
after playing with it for 2 days i was not able to figure out how to switch between languages

Folks

A couple of thoughts from someone who has never worked with XOOPS or any other content management systems.

I've had some requests to make one of my websites multi-lingual. However we have a few quirks that I haven't yet seen mentioned in this very interesting thread.

I would like to support an unlimited number of languages. But as my content is informational, and not commercial, I will be relying on volunteer translaters. Thus, while the more common languages might be available for the most popular pages, other pages might only have a few different languages. So if a given page isn't available in the chosen language I'd like to see it default to the base language, in this case English.

Portugese, I think, is similar to Spanish. Thus if a Portugese page isn't available then I'd like it to switch to Spanish and, if not available in Spanish, then to English. Mind you this likely won't happen often. Or maybe it will. I don't know. This is likely a low priority request as, presumably, there would be buttons somewhere on the screen which would display all the available languages for this particular page.

I will almost certainly be having multiple translaters for a given language. I'd like to ensure that all the translaters be notified of any new/changed pages.

I frequently add, update and much less occasionally delete, a link, sentence or paragraph to a page. It would be nice if the translaters could somehow see the changes highlighted.

It would also be nice if the older version(s) of the pages were available for comparison purposes.

It would also be nice if the translators could see the base language version on the left hand side of the screen and the current translated version on the right hand side of the screen. Or top/bottom, right/left, bottom/top as the translater chooses. After all some languages go top down and others right to left.

And, finally, I think , it would be nice if a user could comment on an awkward translation which is sent to the translator(s) responsible for that language.

Just some random usability thoughts on my part.

Thanks for reading.

Tony Toews

Tony, some very interesting and relevant ideas... thanks for taking the time to write them down! I've been doing a lot of thinking about this recently too and have similar 'needs' in mind for how it should work. I will try to collect all my thoughts and post something coherent here in the future.

I think the points about version "history" to notify translators of changes is quite important. For the PHP manual pages (http://www.php.net), they use a CVS scheme to allow multiple people to translate pages. Essentially, the "original language" (english) page has a version number. Translators set the version number of the translated page to version of the english page which the translation most closely matches. If a translator translates multiple changes at once the translated page version number can jump ahead right away. I think this could be reasonably well emulated in a CMS like xoops.

I like your idea about the comments *about the translation itself*. I wonder what is the best way to implement something like this. Perhaps every page viewed in its non-original language could have an icon/link leading to a 'comments on translation' page. I think these type of comments should be kept separate from the main comments system that currently exists for news, etc. Maybe it could be disguised as something like 'feedback to webmaster'. There could be an automated form for sending feedback, perhaps indicating the page the comments discuss, and maybe a dropdown of 'subjects' (e.g. awkward translation, correction, etc...).

As far as multiple translators goes, I guess you could use the 'groups' feature to handle that. Certain groups would have rights to 'edit' a particular language version of some piece of content. This group could also serve as the target of notifications. It could also be used to route the page 'feedback' if the subject 'awkward translation' was chosen. Maybe there is a better way to handle all this. When a member of the translator group views the page, there could be some automatic indicator if the page needs updating, etc...

Anyways, just some additional random ideas...

You are quite welcome. FWIW I've been a programmer, now called developer, systems analyst, etc, for about 25 years so I think about these kinds of issues all the time.

I'd like to keep the "comments to translators" as a seperate button rather than "comments to webmaster". This way it's quite clear to non base language users that we, as the website owner/translaters, are actively looking for suggestions. After all the volunteer translaters are not paid staff and are certainly not expert translaters. Also being a Canadian I'm aware of differences between Quebec French and France French. Being monolingual I have no idea what those differences are.

Ideally this emailed feedback would, not only indicate the exact page the comment is about, but would have a URL which the translator could click and bring up the base language text and the language specific text side by side so they could make the correct as quickly and easily as possible.

I'm not at all familiar with XOOPS so if you feel the groups implementation would work then fine by me. Hmm, another thought is that if one translater closes the comment then other translaters, if they click on the URL should be notified accordingly.

Also note that a website which is doing this kind of thing, which is quite relevant in my world, is http://www.trigeminal.com. While I don't know what kind of system Michael is running in behind the scenes, you can certainly see what his vision is. Michael is also an employee of Microsoft and is working on ensuring their products support many languages.

Nothing really to add, but regarding the 'comments to translator'... the ideas almost sound like a 'bug tracker' system (i.e. especially about 'closing the comment' once the tranlsation has been updated). The mechanism could certainly be implemented much like a bugtracker (or perhaps as some larger workflow system)... I just wonder if it makes sense to have a bugtracker about documents in general. Some 'bugs' could be translation suggestions and perhaps others could be more typical 'feedback to webmaster' type of comments.

-----------------------------------------------------------
I have used smarty in another CMS and made an "article call other article": a smarty template to pick the right text from available alternatives based on user parameters.

This way we can store the different version as a new article and have them evaluated to find the linking code.

For example:
Suppose there's a forum and you post in english. All is normal but for the language field. However the script stores the message in two parts:
1. A database entry with the actual message but stored in a special category that matches the language selection.
2. An extra entry located in the proper category (that the user browse) which store the smarty code with references to the entries of the different languages.

Basically it just takes some php code to be adapted to any module calling this kind of text and can be used not only for languages but for anything with version selection.
I call it "bridge component" and may take parameters from custom variables like user level or shopping cart items.

-----------------------------------------------------------
I think we dont need a new core release for this, just a set of basic modules. To have full multilingual the core pack should came with all these features (as i review):

- Message tools
1. the "bridge", component to be included in the modules.
it uses smarty functions to fill variables as need.
2. basic smarty templates for the modules using it.
like articles, news, forum, catalogs, etc.

- Site tools (these are important!)
3. a module to edit the translation texts. there are preferences in the admins areas that can be named here.
this avoids having custom symbols that dont match every language files and also provide default values.
4. redo the default themes to change "images/icons" to "images/languages/icons" with every image url in the templates in the core and in the modules. provide the variable to fill in the language in custom themes. this can be combined with additional translation texts.

- To select the language
5. the selector module, set as language selector for the users.
6. the same selector module but generic, in the admin areas, that pass variables to the "bridge" component.

-----------------------------------------------------------
The module that does "machine translation" should not be included in the core pack.
Custom modules and templates should still be done by the webmasters since these reflect the site needs or business.

Hope these ideas help to speed up the multilanguage development as possible.

Thanks for the explanation. I usually don't know how to figure this out. I guess a programmer would handle it more easily. Your posts are like real tutorials.



Appliance parts