When you say more databases would be 'better', could that also be : one database but different records?
(After my Post I read 'Herko was here'and gave allready an answer.)

Basically we can handle things then like this :
The user types some text using square brackets or a more sophisticated method to indicate the used language.

The user hits the submit key

A function looks for the square brackets and sends the content (between the brackets) to the assigned database or records. If there are no brackets you can choose to save the text in all the databases/records or just in one (and using pointers to that one for the other languages)

Aloha

I believe that one of XOOPS best features is not being acknowledged, that being the simplicity of not just administrating but with assigning various groups certain privilages, such as adding content.

Certainly most admins don't shy away from hacking here and there, and easily will adjust to using brackets, however I think we are seeing trees and not the forest for what it is.

I am currently working on a multilingual site with both Russian and English and cannot expect, nor really want to go to the trouble to teach people I am intending to post content, on how to properly use square brackets. To you an me this may be a simple thing but what about others? (This does not even address what has already been brought up concerning unecessary data passing through the TextSanitizer)

I feel at the table level a field should be added specificaly for languages, and as content is added, the language is selected. If you want your content sent to all then code can be written to pass everything through.

For example, my Russian half of the site will be different than the English. Why should I have somebody looking for Russian only content have to sift through English? A great example, though not necessarily the only one would be the way PostNuke handles languages (though I am not familiar with how their code works behind it, I am only referring to the tables).

Does that make any sence?

Chris

I don't really feel fitted to get into a deep technical discussion, however here are a few thoughts in not a very particular order:

1) There seem to be two kind of language requirements for web sites: either the languages are completely different (ie different content in each language), or they are complementary (ie the same content published in 'n' different translations). It should be possible to handle both.
In the former case, it is fairly simple, you can do it like eNvolution where EVERYTHING that could appear on the page has a language parameter (blocks, modules, articles, you name it). The parameter includes "all". Depending on which language the user chooses, then he will see content for that language. This would also mean "detaching" blocks from modules, so that I could have 'n' blocks using the same module, but for different content.
In the latter case it is a bit more complicated, because you would want to make the level 'article' (or 'topic' or 'section' etc etc) into a link, so that for example I could instanciate the same article 'n' times in different languages. Oooff!

2) Separate admin and content. Admin language means translating the whole system's admin menu. Content language should merely allow you to add another language parameter to the system, perhaps with a few attributes such as character set for content entry (definitely NOT hard-coded, otherwise how do I choose the multiple different versions of Korean for example) and with total support for Unicode.

3) Keep it in one database - no point in doubling up a lot of tables you won't necessarily use.

4) Definitely provide an alternative to square brackets. All honour to the hackers who thought this up, BUT in a world of multi-lingual and non-technical users spread around the world, believe me it is EXTREMELY DIFFICULT to explain the simplest imaginable things, and to a non-techie square brackets AIN'T SIMPLE!!

My pennyworth for now, and if anyone can help with my user permissions problem, I'ld be grateful!!

JoelG

Just a quick note. (I'll be back with more later).

joelg wrote:
Quote:

I agree. For most people it's not simple, and thus a better solution should be developed!
However, we should also keep in mind that for some systems the square bracket approach would be alot easier to use. We should also keep in mind that there are several other hacks where square brackets in combination with the text-sanitizer are beeing used.
Therefore I think the multilangual hack should be integrated into the system, and system and module designers should be taught to parse all non-static text (text not included in the language files) though the text-sanitizer unless the text is to be edited.

Quote:

First of all, this approach will not remove the square brackets for the common user.
Second, we would have to introduce a function a disassemble the line, and sort it into various threads in the database.
And third, if somebody desided to edit the text, we would have to assemble the line with square brackets again from the various threads in the database.

I fear it will be very troublesome.

Quote:

I agree.

Some thoughts on how it could be implemented:

Xoops has core functions to help developers display just about anything on the screen. If we want a heading, wi'll call the heading routine in the core. If we want to display a string, we'll call another core routine to display the string. But if we want to edit the string, then we will call the same core routine but with another set of parameters.

I belive (but I haven't checked) it's the same for database access, call a routine to fetch information and another routine to store it. (If it's not there, then it's probably about time to have it implemented!)

This is something I belive can be expolited.

If every user gets the opertunity to make a prioritized list of languages which the user would like to see aswell as not to see, then the routine which is responsible for fetching data in the database could always return the first language in the list which had any text entered.
It would probably be relatively easy to implement.

Entering the texts would be abit more tricky, but by pathcing the right core functions - such as the ones to edit a string, described above - it would be possible to make a loop inside the core function, which would return eg. four strings with four different languages, instead of the one string that was origially ordered by the programmer.
The user entering the text would then enter text into the strings he wants to, and the core function responsible for storing the text will automatically distribute the text into the correct language threads in the database.

I don't know if it's realistic approach to addmultilagual support in this fasion, but it seems to me to be a relative simple way to reach most of the goals a multilangual site could want. (Although, it will not allow you to link to a specific languageversion of a certan article!)

Please think it over.

Quote:

I like this idear - even if the amount of languages supported by those translators are relative limited.

Best regards.

Quote:

Agreed. I used to work in a company whose site was translated in 5 languages. Once an article was added in one language, translators team was notified of it, then they could go the the admin interface, click "translate" and the article was duplicated ready to be translated in another language.

If you want to talk of interface stuff, it means:
- One possibility to indicate the languages available somewhere in admin + specifying a default language
- An additional selectbox (containing the above languages) in each form used to submit content, allowing poster to specify which language is used in his post
- A "translate" button available in the forms/admin, so an item can be duplicated and used as a starting point for the translation while staying "linked" with the original
- An additional pref for each user, allowing them to specify one or more languages and the order of preference

Technically, we don't even need to duplicate tables or have separate ones. It's just about creating another table that links content to languages.



transid is the primary key,
newsid allows us to retrieve the news item by itself
univnewsid is what links translations
lang is the language code of this item

Another (and more simple) solution would be to add the 2 (univnewsid + lang) columns to the existing content tables.

So, if we create a entirely new news item, it is added to the news table as usual, and a row with a new univnewsid is also generated.
If we want to translate an already existing news, we duplicate it, change the content, and add another line to the translation table which will have the same univnewsid as the original.
Like this:
- we can query the items in a specific language
- we can also query all the translations of a specific item using the "univ" field (to show a "translate to" selectbox in the article page that will give people access to available translations)
- If using the "additional table" choice, we can even trick the system so the same item is marked as being in different languages, without the information being actually duplicated (i.e: some admins may want a specific english item to appear in all the site even in foreign versions)

etc...

For core/module handling: a little part should be handled by the kernel itself (specifying avail languages / user pref), but module writers will have to take care of the rest (anyway it's not too difficult to implement I think...)



Skalpa.>

Dear Xoopsers:

At this time, several of us in the core team have had lengthy conversations with onokazu, Xoops' lead developer, about the future of multilanguage in the XOOPS frame. The technical details are too far from my understanding to be able to comment them, but I just wanted to say we're in the process of thinking about the best solution for all.

That said, I'm in the process of building a multilingual version of the XOOPS 2.0.5a package. The idea would be to include in the downloads this hacked version so people needing to publish their sites in several languages don't have to go through the problem of applying the hacks one by one. Of course, it'd be necessary to edit the sanitizer depending on the languages wanted, and to add the language files. All in all, the idea is just to offer a temporal solution that alleviates some of the problems.

Anyway, this thread is very valuable and should continue. Many heads maybe don't think much better that one, but they sure can offer different insights, and multilanguage is an issue where we need all the different insights possible. This comes from somebody who uses spanish as its mother tongue, in a core team lead by a dutch, for a software package developed by a japanese, and... you get the picture.

Cheers.

Regardless of which method is chosen to implement multilanguage texts, in my opinion it would be nice if the URLs can be kept as clean as possible. Perhaps keeping the language preference in a cookie, instead of as part of the URL.

In other words, no &lang=en in the url. I guess I'm old fashioned, but, I still prefer human readable URLs.

Don't forget. You need to think hard about specifying the code pages for the different languages, and also making sure that the interface for entering content doesn't do nasty things to the content (like converting it to "&xxxx" ) when you enter it, no matter what your local machine's settings (eg entering Russian from French Windows/XP!!)