Mikha, realmente tem algum problema com o arquivo. Como da vez que comentei que o xoops.bz2 que tinha lá no site tinha problemas, este arquivo tem um tar dentro que não abre de jeito nenhum.

Ia postar isso no site mas tá impossível de usar de tão lento, é só comigo? (tipo dez vezes mais lento que no pior dia no sourceforge).

Abração.

Thanks Herko, that was what I meant by Quote: but I didn't make myself clear enough.
I believe ideally the possible content languages should be hardcoded and linked to equivalent charsets and interface languages, is there any obvious flaw in that?

Would there be any kind of performance loss associated implementing a feature like this?

They way I see it, separation at the database level would be the best approach.

Xoops core would have an option to turn multilanguage content on or off, if it's on you´ll have to choose which N languages are supported. The database structure remains pretty much the same, except that for each content item you'll have N separate content, identifiable some flag that both allows editing of a given language version and displaying of a given version. Perhaps the language selection already available could be enhanced so that when a user changes it, the content, interface and char-encoding are affected.

So we have the same space use in the database, 1/N the bandwidth used in the square brackets way and the ability to make language driven searches. A default of showing all versions if no language code is set by the client makes this approach very search-engine friendly. A feature to generate Babelfish or Google-like translations for a quick and dirt version in languages the author can't handle would be nice too.

What do you think?