Proposal: Multilanguage administration in database instead of lang.php

English forums
1

Currently the language definitions are stored completely in several flat files (lang.php, see http://www.oxid-esales.com/forum/showthread.php?t=1947). Therefore, changing the shop texts is only possible for the shop owner if he is able to use a text editor and has user privileges to access different shop directories (e.g. /shop/out/basic/en/lang.php). Most shop owners want to alter the template texts according to their need.

The current technique of changing the language definitions in lang.php files has several drawbacks:

  • Most shop owners are not able to use a text editor to change the language definitions.
  • A shop owner should not have the right to access the directories which hold the language definitions because of security constraints.
  • Also, it’s to dangerous to let someone without php knowledge change php files. One syntax error, and the whole language definition could not be read anymore.
  • Usually a show owner doesn’t want to work anywhere else than in the shop admininstration.

Nevertheless the shop owner should be able and often wants to alter the different shop texts without the help of a shop developer.

Therefore I’d like to propose a change of the current language implementation technique:
All language definitions should be hold in the database and no more in flat files (let’s say, a “template cms” compared with the normal cms).

There are different advantages in storing language definitions in the database instead of lang.php:

  • The shop owner is now able to change the text definitions by himself.
  • The danger of creating bugs when changing the language definitions is zero.
  • New languages could be added simply by the shop owner himself.
  • Third party shop translaters could have access to this special “template cms”.

I don’t think that there will be any performance issues if the database table with the language definitions is called once to initalize the language array. This should not make much difference to the current method. If this is an issue it would be possible to offer the old method as an option.

I am very sure that show owners would appreciate this described. method. And by the way I am sure that shop developers would appreciate this method, too: It’s very boring for a developer to have to change shop texts in lang.php.

2

[B][U]No, no, no, please do not!!![/U]
[/B]

The experience with the Gambio Shop-System (which is also using a DB-based langugae scheme), strongly indicates, that [B]most anybody[/B], who is doing adaptation work in this area, [B]strongly dislikes [/B]this approach. (Not even to mention shop-design agencies like us…)

It is [B]at least 10 times [/B]more time consuming to change a text this way, instead of using a text editor. (By popular demand, I therefore have developped a PHP program for Gambio, which is restoring the original [B]file based language handling [/B]to the Gambio shop.)

Not to mention the heavy load, which is imposed on the database by reading 2.500 odd texts from the DB…

[B]Another important aspect is language translation.[/B]

How would you handle this with a DB-based approach?

Now you can ship the language file to a translator, and you’re done.

Just imagine to translate 2.500 odd lines of text using an admin-based DB-interface…

3

Hello avenger,

first of all, I think there is no need to shout. Thank you.

Well, I am just talking of my own experiences and of the experiences and wishes of my customers (which uses PE3 where I implemented a database based template text approach in the way I described above).

The experience with the Gambio Shop-System (which is also using a DB-based langugae scheme), strongly indicates, that most anybody, who is doing adaptation work in this area, strongly dislikes this approach. (Not even to mention shop-design agencies like us…)

The experience with the OXID PE3 strongly indicates that my customers like very much to have access to the template texts and to be able to change them with the help of the admin panel. Obviously, we have different type of customers. My customers like to type text in the admin panel. But they would not like to type text in a text editor with the danger to forget a comma at the wrong place.

It is at least 10 times more time consuming to change a text this way, instead of using a text editor.

This may be true for different types of customers. Otherwise it may also be 10 times more consuming to find a syntax error in the language file. I did not here anything from my customer that it took too much time. In contrary, it’s very fast to alter a certain entry in 4 different languages without the need to download/upload 4 different php files.

Not to mention the heavy load, which is imposed on the database by reading 2.500 odd texts from the DB…

After a look to the lang.php make me think of about 1200 records… I haven’t tested it, but to read those 1200 records into an array shouldn’t make too much load compared to the normal database calls of the Shop?

But ok, I take you seriously: For those with a slow server I wrote in my proposal that there could be an option to fallback to normal language files. Another, probably much better approach would be to generate the language files on demand if the database content has been changed meanwhile. This ‘language cache’ would be probably the most elegant method where everybody has everything what he likes: You could disable the database template cms and work directly with the language file. And my customers use the admin approach, and after a change the language files are generated. The would be the best of two worlds where everybody gets what he wants.

Another important aspect is language translation.
How would you handle this with a DB-based approach?
Now you can ship the language file to a translator, and you’re done.
Just imagine to translate 2.500 odd lines of text using an admin-based DB-interface…

There are several methods. My customer liked to change the texts himself, i.e. the translator got and returned the texts in portions (Excel). Another approach would be to export as csv/Excel and import it back. Should be very easy. I would not advise to give some translator files with php syntax, and I would not like to correct the syntax when I get the files back. And I know there will be syntax errors…

But ok, thanks for your opionion and sharing your experiences. Would be nice to hear what other developers (and oxid) think about this approach.

4

Hi there,

well actually, a change of the lang definitions is not needed every day so it would not matter what the shop owner knows or likes in most cases, would it?

Having a GUI tool like this one http://www.i18ntranslation.com/
it would be much easier to change existing entries and install new languages to the shop system no matter where the translation goes.

A performance test on what works better either text or SQL based database is still left…

Regards

5

Hi,

yes of course, after everything is done, there is nearly no need anymore to mess around in the language files. But until then, it is much easier for everybody:

  • the shop developer does not have to coordinate and integrate all those small text changes and is not getting tired with this boring work…
  • … because the shop owner does it himself

It’s always better to let the shop owner be able to change the shop content by himself than to forbid him to do so. Naturally, he is able to do it with his product description. Why shouldn’t he be able to change all his shop texts, too? And it is necessary to change everything according to his needs because every shop owner sells his stuff to a different kind of customers.

A performance test on what works better either text or SQL based database is still left…

If it would be done as described in my second post - the language files are generated on demand - there are no performance issues to be expected.

BTW I have made experiences with both language techniques: One of my clients works with Frank Knapps language module (PE3) - nearly similar to the current lang.php solution - , and another client works with my custom made CMS solution. The CMS solution works much better/elegant for my client (and myself). I’d like to concentrate on more important stuff than to change language texts during and after shop development.

6

Oh my god, i really read the whole thread.

I am happy with the solution as it is right now.
I just hope Oxid will find the right way for the future.

CYA
Firefax