I just made a module in a hurry. This module is another news-module. Someone complaining about yet another news-module? Basically this module is really stupid and full of bugs, because I stripped away all the bloated code from the new debaser-module just to keep ONE feature. A feature which is IMO unique: writing multilingual content without any annoying markup for every single language.

How does it work? First of all the module "news" (get it HERE and sorry for the bad module-name) must be installed along with xlanguage 3.xx. For xlanguage the basis languages must be defined (atm German and English) and the block with the flags must be displayed. debaser erm news reads the available languages from xoopsroot / language and displays the languages as flags when it comes to submitting news. At the start input fields for the "active" language will be displayed. Click on the other flags to toggle input fields for the other languages. Atm this works only for German and English, because these are the only delivered languages for the module. In theory!! all?? other languages could be eventually possible.

As already mentioned this module was made in a hurry and is full of bugs, but works with 2.3.2.

For those who are extremely bored and have too much time may have a look at this thing and judge if it is a) crap b) totally crap c) mega crap or d) quite usable.

If d) I would develop this further for debaser. I am looking forward to all the positive feedback (negative feedback will be ignored).

P.S.: As a "gimmick" the module still has a flashuploader. This uploader would upload anything into xoopsroot / uploads / news if this directory would only exist and if this directory is writable.

P.P.S: I forgot to mention that this module is ugly as me!

Can you rename it to something different? Having it as /news would overwrite my installations of Herve's News module, and I cannot do it.

OK, I've renamed it and was able to test it!

The verdict is D

Now couple of feedback issues:

* I assume that it was only a test of the backend, as on the frontend I was able to "submit", but there was nothing visible when I went to:
http://localhost/xoops231/modules/newsblack/index.php

Of course, I was able to view/modify the submitted content from the Admin menu

* If I remember correctly, you've mentioned couple of months ago that this solution would allow to store each language files separately, thus we would never run into a problem with not sufficient space for the title, if we have a long title and more than two languages as it is right now. Therefore I think this would be a very useful feature.

* But it would be the most useful feature if it would be part of the core, i.e. we would make the core multilingual with xLanguage and your solution, and then every module could could tap to it and define each its field as multi-lingual.

* The next question will be how to make an easy translation of the content, i.e. if you release it in English, how could people add more languages in a very easy way. The "lang_tool" has a good concept for it - you might take a look into it.

In general, whatever will help us to get away from field size and number of languages limitation, is a very good thing!

So I very much appreciate your efforts!!!

Quote:

As stated: full of bugs, maybe I forgot to pack a file? Because for me it is working.

Quote:

You remember correctly. This was the aim of my little experiment.

Quote:

I would be honored if something of my code would make it into the core. To tell you the truth: There is nearly nothing what could be part of the core. Perhaps some javascript snippets. What gave me more headaches was the tree presentation for categories. It gets even more complicated, when permissions have to be used. For my news-module-experiment I stripped the permission part. The newstree.php is a hack from xoopstree.php I found somewhere, which I again hacked to adapt it to my needs. I guess, no I KNOW, that there will be smarter ways of coding this. So this part I would leave to the PHP-Pros.

The only languages I speak (more or less) are English and German so it would be exciting what happens with other languages.

Quote:

Abolutely...

Quote:
Too bad. We're definitely looking for a better solution addressing multilanguage issues, as the current one where we have to store all translations in one place, and thus run easily out of space, is not satisfactory.

However, your approach might be a good one for modules developers who could follow your steps and create multilingual solution at the module level.

I'll definitely follow your work with great interest, as internationalization of XOOPS is one of my "pet projects"

Don't be too disappointed! I'll try this weekend to "hack" the core just for YOU! But I need your assistance.
a) Is it absolutely necessary to hack the backend? The administrator should know what he/she is doing. So IMO the presentation on the frontend has to be fine.
b) Blocks need to be multilingual, because they are shown on the frontend
c) The modules names need to be multilingual, because they are shown on the frontend e.g. in the main menu
d) The imagemanager
e) what else?

Well, in a perfect solution, we would not only make the content multilingual, but also have a replacement of all the admin "language files", incl. the back-end

As we're offering XOOPS to more people from around the world who might not speak English, it's important that also the back-end is multilingual.

The challenge is to make it a solution where:

- module developers can easily add the Multilingual feature to their modules (like it is done with xLanguage)

- modules owners/admins can easily extract all local text and give it to translator for translations (right done with "language files")

Currently the process is pretty simple and easy. However, it is limited by the need to store everything in one field. So if we could keep the simplicity of the current process, but remove the storage limitation, we would make a lot of people very happy

How stupid! Best things come when you are not expecting them. I guess I just found a better solution assuming xlanguage will part of the core in the future. So I will do a makeover for my little test-module this weekend (even with a better name). If this works as I hope, then this could be used for the core as well.

I think that in the backend things could get a little bit complicated, if you want it also multilingual. You will need two language selectors: one for the interface language and one for the content that is administrated.

An idea for a possible setup in XOOPS could be a language table, that defines the language. It has following fields:
- id: autoincrement key for identification of the language.
- enable: to enable or disable a language
- ISO: kode eg en
- name: eg English
Preloaded with 0 - English and configurable by the user for other languages eg 1 - Deutsch.

In News, the key field is no longer the id but the combination of id with the language code. This goes for every table as articles and categories. These can no longer have autoincrement fields, so there has to be a new table with a single autocrement id field, which will be used to generated the Id's.

All articles and categories can have this way a record per language, without having to divide it with the needed languages.

Articles are looked up by their article id as now is the case, combined with the desired language id. The language can be remembered by a cookie or come from the multisite hack with one subdomain per language.
If an article - language id doesn't exist the user is offered a choice of the existing combinations.

In edit the article is created in the users language. It offers links to the other languages to create/copy or edit them.

For the backend some configuration tables could also store different settings per language by adding the language id to their key.
The settings have a selection that allows to save the modified settings to one or more languages.