Aug 29, 2008 | 12:29 PM  
Welcome

Don't have an account yet? You can create one, it is free, just click here

as a registered user you have some advantages like free downloads, comments and posting on our forums, depending upon this site's configuration and options.

 • •  Control Panel - Register - Login  • • 
Current Stable MDPro Lite 1.0821 Download
   19-Oct-2005  Print current page  Show map

Languages, Language Packs and Translations

Duster

MDPro supports many varied languages, including invented languages such as Esperanto and Klingon. From English to Arabic, Russian and Chinese, irrespective of language character set, left to right, right to left, or top to bottom writing, MDP likely supports it.That does not mean, however, that a language pack can be found in any language. What do you do then if you are unable to find a current and accurate translation for the language(s) you want?

The first thing to do is check if the desired language pack is available.

The multi-national nature of the MAXdev project means that the available language packs are likely to be good translations because they were probably created by native speakers of the language. However, if you can't find one at all and decide to undetake the task of translating a language, the following information will be helpful.

Translating

Possibly the easiest way to translate a MDP language pack is through Nubel, available at http://canvas.anubix.net/. It is a tool that greatly facilitates the task of translation.

There is also the entirely manual method described below by kras_gadjokov for PostNuke

Assumptions:
- all directories are relative to your MDP install root
- xyz is the 3-letter abbreviation for the desired language. To find the abbreviation for your desired language, in Admin Menu -- Settings -- click on the drop-down setting Select the language for your site

IMPORTANT: the step Generate below is supposed to create directory language_xyz with subdirs and files to be translated.
But it FAILS very often to create it at all (MDP 0.726 will NOT give error message about this).
The reason is permissions - my advice is to create it manually and give chmod permissions 777 (755 will NOT work!) and AFTER that start with the procedure below.

Phase 1: Generating the new language definition files

1) create an empty directory language/xyz
(without this you will NOT have a drop-down choice for your language in Choose Language in step 2)

2) in Admin Menu - Languages - Choose Language - choose desired language

3) choose Constant Loading
(takes time- be patient, may take few minutes!)

4) choose Load Translations

5) choose Add Missing
(takes time- be patient, may take few minutes!)
As result, will show a page with a list of all non-translated constants to translate, by file.

6) choose Generate
This step will result in creation of directory structure under language_xyz with php-files with language constants' definitions.
List of the files and directories created will be shown on the screen.

Phase 2: Translating

1) translate as many constants as you can (or want) in the file language/xyz/missing.php by replacing the second parameter in the define statements with the corresponding word/sentence in your desired language. How to find the corresponding English word/sentence - see Problems below, #1

2) run again the round Constant Loading -- Load Translations -- Add Missing -- Generate
As a result, the translated constants will disappear from missing.php and will show up in the appropriate file under language_xyz directory

3) Repeat steps 1 and 2 until all (or all you need) constants in missing.php are translated
(be advised there are about 2200 constants to translate in version 0.726!)

4) when ready with translation (or part of it), copy all directories (with files and subdirs) that are residing under language_xyz to the ROOT of your MDP installation

Problems

1) in some older PN versions, missing.php used to contain - as a comment on the same line for the particular constant - the ACTUAL English text from the corresponding English language file, which was VERY helpful, since you would just look at it and overwrite the second define parameter on the same line with the actual text in your desired language.

Not with version 0.726! What happened? Instead, now it contains useless information - the location of the actual language definition file under language_xyz it is supposed to show up after being translated

To translate, now you have to first find the actual English text for the particular constant in the same path/file, shown on the same line in missing.php, but relative to the PN root install

2) if you get to a page that uses some non-translated constant, you will see an ugly LONG line containing the constant name AND the full path to the file where this constant definition resides. To avoid it - since you cannot possibly test all pages your visitors will be able to get to - you really have to translate ALL 2200 definitions.
Reuse of older versions language packs in new PN versions Imagine you have the desired language translated and installed in an OLD-version PN installation. How can you use the existing definitions that are the same in the old and in the new PN versions, and translate much less in order to create the new PN version language pack?

I have created a Perl script which does exactly that, and created Bulgarian language pack for MDP 0.726 using the existing 0.723 lang.pack. Thus, I had to really translate manually ONLY about 10% of the total 2200 definitions (only the newly defined in the new PN version)

I can offer the script for $20 - the requirements are not to give it to anybody else and not to remove my name from the credits.
I know this cannot be enforced - so I am relying on people's honesty. Or I can do it for you myself and you will ge the ready-to-use new lang.pack (you will still need to translate the new definitions manually). If interested, contact me at my website http://www.incredium.com

The script is also:

* independent of the directory structure and changes in it and definition file names and locations - as long as the definitions have the current syntax (which has been the same from v 0.703 to the current 0.726), it will work.
* capable of replacing non-translated constants with the English equivalent - it is much better for the users to see something in English, as opposed to some puzzling constant names and file paths

To those that may question my asking for payment and my contribution to the PN project and community, I would point to read about the knowledge I have shared so far in this forum among my postings:
http://forums.postnuke.com/index.php?name=MDPphpBB2&file=search&search_author=kras_gadjokov

Now that you have your language pack, you will need to prepare for the addition of it to your site. Check the language availability in the Settings menu where it says Select the language for your site: If you don't find your language listed there, you will need to add it using the following instructions:

Add this line

"$lang['xxx'] = _LANGUAGE_XXX;

to html/modules/NS-Languages/api.php and then add this line

define('_LANGUAGE_XXX','Language_Name');

to all html/language/<languages>/global.php files.

xxx stands for the 3-letter code which you can find in http://www.w3.org/WAI/ER/IG/ert/iso639.htm

Be sure to list the language name in its respective language. It does no good to list the language in English or any language other than that of the language being added. There may be limitations based on the character sets used by various languages. Through the use of utf-8, languages that do not use the Roman character set could be displayed properly in their respective language and characters. This includes Russian (the Cyrillic character set), Greek, Hebrew, Arabic, Chinese, etc.