Easier language and strings adaption

[helios]

This was previously bug 1005... now posting here on request.

 

Summary:

Language adaption of osCommerce without having to change distribution language files

 

 

Hello,

 

We are currently trying to adapt osCommerce to use it as our new online shop system.

 

To do that we found out we have to change quite some strings in the language php files. There are three cases for that:

 

1) we change some strings to adapt the output to our needs: this is for example with various email related strings

 

2) we add new strings for our own additions like own boxes

 

3) we change some strings to correct some typos in the german language (these we would like to report the the maintainer of the german translation)

 

Changes for case 1) and 2) are not needed to be implemented to upstream releases. Changes for case 3) might make sense to implemented to upstream release if the maintainer sees them fit.

 

Now defining new strings or altering existing strings by changing the language files directly means that you have to merge your changes with the release files on every single update of the shop. You either find out what has changed in the release files and implement that changes in your own local files, or you use the release files and implement all your changes once again. Quite tedious!

 

I now implemented a way to implement changes to the localization strings without changing the release language files. It goes like the "local/configure.php" idea.

 

In "application_top.php" I added some commands to load a local language file right before the main language file is loaded, just like this:

 

// H&P: load our own language definitions

// these are loaded before the main language localization files and thus

// can override strings in them, Helios, 3/2003

require(DIR_WS_LANGUAGES . $language . '-haagepartner.php');

 

Now I could define new strings in "german-haagepartner.php" file for example or I could override existing strings since "german-haagepartner.php" will get included before any other language file.

 

This approach encapsulates all my changes to the localization strings in local files and thus I do not need to fiddle around with the distribution language files of the shop on each update. I may still choose to report fixes in the german language to the maintainer of it - and get rid of my local bug fixes once an upstream release contains these fixes.

 

What I suggest now, is to implement a standard way for this approach! Maybe use "german-local.php", "english-local.php" or something like this.

 

This would at least minimize the number of distribution files you need to change.

 

Actually a big version of this approach would be to separate distribution files and customization files incl. templates from one another to make updating the shop a breeze. But this could be a good start for the localization strings.

[Druide]

That sounds like a very GOOD solution to me,

currently i am translating my client's website in 2 other languages then English and it is for sure a very confusing & time consuming job.

 

Because i have installed a whole lot modifications & made myself even more i guess but now i need to translate all those strings.

 

The way i work right now is open file x in english and german & dutch

and then compare them english -> german with the program Ultra Edit

Then i need to add make all changes and continue to next language or file.

 

You do understand, there is absolutely no fun in this part of creating a multi language website, but i'm sure it will pay off someday :)

One way or the other...

 

When i have done all this then i start the Spanish translation...pfff

 

This job is making me at least 10 years older..haha

 

Anyway i like the idea of yours about the language files