| Re: I am looking for laboratory rats! |
| by frankblack on 2008/12/2 1:36:38 This took me a bit longer, because I had to move some furniture over the weekend (lame excuse). This module is really simple, because it is only meant as a techdemo. What you have to do: XOOPS 2.3.2 (required), install the module, install xlanguage 3.01 (set up German and English as base languages). Define categories, write content. If you find bugs, keep them.  How it works: It is rather simple and more a "hack". The annoying part with the multilingual solutions was the fact, that you always had to type in the markup for each language. Now you do not have to type the markup, but it is invisibly there. En detail: Every time you write something multilingual, a config-file of xlanguage will be read. The base language are read and will be displayed as flags or input fields. When it comes to saving the content, the language markup will be added by the script. When you edit this content, it is going the other way round. The markup will be deleted and assigned to the input fields for each language. This is "just a hack" and far away from being a multilingual system. The advantage is, that this hack is simple to implement (even in XOOPS-Core-areas, you also have to do some database work to change database fields for being bigger). A true multilingual is everything but trivial. Who is interested might have a look at the "code", which is far from being optimised. Have fun testing and reading spaghetti-code.  You can get the module HERE |
| Re: I am looking for laboratory rats! |
| by ghia on 2008/11/28 17:25:13 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. |
| Re: I am looking for laboratory rats! |
| by frankblack on 2008/11/28 16:13:15 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.
|
| Re: I am looking for laboratory rats! |
| by Mamba on 2008/11/28 15:33:10 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
|
| Re: I am looking for laboratory rats! |
| by frankblack on 2008/11/28 15:19:31 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? |
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $15.00 |
| Due Date: | Jul 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $15.00 |
|
|