PostNuke

Site search

Search results

Number of hits: 11

Using PostNuke and MySQL in Unicode (UTF-8)   (News)

MySql and UTF-8

by: Bernd Plagge
www.choicenet.ne.jp

MySql introduced support for different character sets and collating rules in version 4.1. While this has many advantages databases sometimes need to be migrated and then we have to ensure that the correct character code is set for the new database. We are mainly using UTF-8 and hence you may have to adapt this information to your situation!

What is the problem?

MySql uses as default Latin1, swedish flavour.
How do we check this?

run mysql.
mysql> show variables;

How to check the character set for a particular database?

run mysql.
mysql> show create table


The character code can be set in various places - so where is the best place for this?


We always use UTF-8
------------------------
In this case it makes sense to set the character code for the whole server to UTF-8. MySql actually sets the character code at different levels:
server
client
database connection
database

The character encoding for server, client and the connection work hand in hand to ensure that the data is interpreted correctly. It seems that MySql makes no effort to determine the correct character set but will convert data in accordance with it's configuration. This leads to problems for old databases if the database character code differes from the one configured.

The easiest way to configure MySql for UTF-8 is to put the configuration inot the main configuration file (/etc/mysql/my.cnf).
In my.cnf there are different file sections. So you can't put it just anywhere.

[mysqld]
character-set-server=utf8

[client]
default-character-set=utf8


Setting UTF-8 for one Database
--------------------------------------
You can check the default character code for a database either by dumping the data and then changing the schema file or you can do this online.
You use the 'alter table' statement to change the database using mysql.

run mysql
alter database
default character set utf-8
default collotion_name utf8-general_ci;

note: you may omit the word 'default'.


It is also worth noting that e.g. mysqldump silently adds the default character code when exporting data!
This can causes problems if the character code defined and the database content are different. In such cases MySqldump will try to convert data to it's default character code!
However, you can disable that by adding the character code option when using MySqldump.
e.g. mysqldump --set-charset.

In the same way you may explicitely set the character set.

mysqlimport --default-character-set = utf8
mysqladmin --defautl-character-set = utf8 create


Setting the character code at server start
-----------------------------------------------------
You can start the server with:
character-set-server
collation-server

The current values can be determined with the command

run MySql:
mysql> show variables;


Values may be changed with commands like:

set character_set_server = utf8;
set collation_server = utf8_unicode_ci


Setting the character code within Applications
----------------------------------------------------------
You want ensure that the correct character code is set when connecting to a particular database.

Connect to the database and issue the following SQL command:

mysql>SET NAMES utf8;


SET NAMES is equivalent to the 3 commands:
character_set_client
character_set_connection
character_set_results


How to run PostNuke in UTF-8
-----------------------------------
Several things have to fall into place for this to work correctly.

1) the database encoding needs to be set to UTF-8
2) the application language needs to be encoded in UTF-8
3) PostNuke needs to be told to use UTF-8

ad 1)
see above for details!

ad 2)
The character code for a given language is set in language//global.php (PN 0.76x) or in language//core.php (PN 0.8). Search and adjust the following 3 define strings:
define('_CHARSET','UTF-8');
define('_LOCALE','en_US');
define('_LOCALEWIN','eng');

Of course it is not sufficient just to change the _CHARSET to UTF-8. The text strings themselves need to be encoded in UTF-8. This can be done in a number of ways:
a) use 'recode' or 'iconv' on every language file
b) use the pnlwb (PN Language Workbench) to extract and convert all language files

ad 3)
Following the database initialization you need to issue a "set names to 'UTF-8'" command. As this is done in includes/pnAPI.php we need to patch that file.

PN 0.76x
----------

// load security functions.
include 'includes/pnSecurity.php';

// Load our language files
include 'includes/pnLang.php';
pnLangLoad();

//bplagge 2006-01-31 - charset fix for new MySql version
$dbconn =& pnDBGetConn(true);
$info=$dbconn->ServerInfo();
if ($dbconn->ErrorNo() != 0) {
echo "Error: "; echo $dbconn->ErrorNo();
}
// print_r($info);
$c = _CHARSET;
// Mysql uses non-standard name for UTF-8!
if ($c == 'UTF-8')
$c = 'UTF8';
$query = sprintf('SET NAMES \'%s\'', $c);
$dbconn->Execute($query);
if ($dbconn->ErrorNo()!=0) {
echo "Error: "; echo $dbconn->ErrorMsg();
echo "check pnAPI.php";
}
}
// end bplagge - mysql charset adjustment


PN 0.8
-------

if ($stages & PN_CORE_LANGS) {
// Load our language files
pnLangLoad();
}

# bp 2007-06-01
# need to "set names '' " to ensure correct data handling
$query = sprintf('SET NAMES \'%s\'', 'UTF8');
$result = DBUtil::executeSQL($query, -1, -1, true, true);

Please note that the MySQL character code names are NON STANDARD!

How to check?
----------------
I always found that phpMyAdmin is an excellent tool for MySQL databases. If the data entered in PostNuke is also correctly displayed in phpMyAdmin table browse mode I'm quite confident that everything is fine.

Generated on June 6, 2007.

Development Update, March 2007   (News)

Dot 8 evolving: language files progression and legacy functionality
Thanks to the testing of the community users (yes, YOU!), some legacy functions (residing in /includes/legacy/ have been updated by Simon to solve some bugs. This is another proof that we do need everyone to test the releases and help not only yourself to make this release a success! The following files have also been marked 'deprecated', with an accompanying comment in the DocBlock: admin.php, backend.php, banners.php, error.php, modules.php, print.php and user.php. These files shall be removed in the next (post-dot8) major release.
The overhaul of language files has also applied to the Groups, Theme, Users and Profile modules. These modules now have better multilingual options and (by using the pnML function), making it a lot easier to translate the package and showing better logic in grammar for localisations. Furthermore, lots of open bugs have been solved and the templates have been revised also. For example, the emails sent by the Users module can now be adjusted by just editing a template!
David Nelson has offered to completely review the language files for dot8, and we all have to thank Olaf Fichtner for helping revamp the current language constants. The PostNuke Languages Project is actively following the development!
Important change in the language strings is the use of the _CREATEDBY / _CREATEDON and the _UPDATEDBY / _UPDATEDON constants. For better support in other languages, these are replaced by the following:

'_CREATEDBY', 'Created by %username%'
'_CREATEDON', 'Created on %date%'
'_CREATEDBYON', 'Created by %username% on %date%'
'_UPDATEDBY', 'Last updated by %username%'
'_UPDATEDON', 'Updated on %date%'
'_UPDATEDBYON', 'Last updated by %username% on %date%'

and can now be accessed through the normal pnml plugin in the templates.

System modules: pnForm and PageLock
Jørn has moved the pnForm framework to it's own module location within the system directory. Major reason for this is to properly save some pnForm specific javascript and style files. Usage of the module should be quite the same. In addition, some new context menu plugins have been added. These plugins create a popup menu to be used as a right-click context menu. More information can be found in the added files in the pnForm plugin directory, and at the pnForm Wiki Pages.
Also introduced by Jørn is a new system module. The PageLock module is a module that helps enforcing single user access to a specific page, by blocking access to other users when one has it open.
Example: User A opens article X for editing. This is registered on the server. User B tries to open article X for editing too. But as soon as the article editing window is opened, it is overlayed with a transparent dark film and a box in the middle tells the user "Sorry this page has been locked by user A - please wait or come back later".
Functionality: The lock is maintained by an Ajax plugin that keeps pinging the server as long as user A keeps the editing page open. When user A closes the window then the pinging stops and the lock times out. If user B chooses to wait then his page keeps pinging the server for the release of the lock (also Ajax) - and when that happens he gains access to the page. The module can be used on all pages that edites a single item - articles, user data, news items, book pages, permissions settings - you name it.
To use this system, a module author has to use API calls in their own code for adding or releasing a block: pnModAPIFunc('PageLock', 'user', 'pageLock', ...) and pnModAPIFunc('PageLock', 'user', 'releaseLock', ...). To see al this in action, grab the latest nightly snapshot and play around with the HowtoPnForm module: edit a recipe in one browser, and try to edit the same in another browser.

ValueAddons modules: Members_List and EZComments
The Members_List module has been revised by Mark West, with some added configuration options. It is now possible to set the number of (allowed) registered users, and some new blocks (featured user last seen and last x users) have been added. Check out the latest nightly build to see the functionality and options.
Mark has now finished the integration of categories into the user side of the Reviews, Pages, FAQ and News modules. This way, migration of .7x categories into the new Categories module is now supported and can be tested by our users who want to upgrade their .7 site to .8.
Finally, there have been added configuration options for categorization and category titles in the permalinks with these modules.
One hot issue at the moment is the increasing amount of spam that is on lots of websites at this moment. More and more features are to be found on the internet to prevent spam showing on your site. Akismet / Bad Behaviour are one of these. As some already know, Akismet has been applied in EZCommnents for a while. For testing purposes, Mark has implemented a bad behaviour (http://www.bad-behavior.ioerror.us/) function also for testing purposes (as Steffen has found that this could also be a good application). It does need some code hacking to pnApi.php at this moment, so only advanmced users willing to help integreating this feature are invited to test this and report any iussues to the EZComments tracker at the EZComments NOC project page.

Core and API: ThemeUtil and Categories
The pnTheme system has now been converted to the ThemeUtil class. With this conversion, all occurences in the core were updated too. Both the old and the new file are loaded in pnInit for backwards compatibility, but the old file (onTheme) and its functions are now marked as 'deprecated' and will be removed in the next major release.
Also added to the new ThemeUtil is a getModuleStylesheet method which contains the logic from the modulestylesheet plugin. You can do PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename')) to include the value of pnModGetVar('modulename', 'modulestylesheet') or style.css (in this order) or PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename', 'special.css)) to include the special.css file in your rendered page.
While unnecessary for correct functioning of the website, one is now allowed to turn off session regeneration completely. This is added because it may be helpful with a couple of undecided bugs in the tracker at the moment.

Module Development: information for 3rd party Devs!
Axel introduced a very nice application called EasyDist. This allows you to create your own PostNuke package easily. You can find it at modulestudio.de. It is still in a very early stage, but you should get the idea. This is all still in development fase and is just for testing purposes at this moment.
A preliminary for the (automatic) creation of packages using EasyDist is that module authors package their modules in a standard way. Right now, there are different file structures in the ZIPs or TGZs the authors distribute. We came to the conclusion that the preferred file structure inside the archive should be - modules - MyModule - pnuser.php etc so that an unpacked archive could be copied inside the pnroot. More information is in t

Generated on March 21, 2007.

Call for articles for pnLanguages   (News)

thoughts about the PostNuke language system, the organization of pnLanguages and just about any other PostNuke-related topic you like.
If English is not your mother tongue and if your English isn't perfect, it's not necessarily a problem. That can be corrected. If an article is in another language but is of particular merit, it may also be possible to have it translated into English. All submissions must be your own work.
After some appropriate editing, if they make useful food for debate, they can be published in the pnLanguages news section. And maybe on pnNews, too, although your article will then be examined and considered by PostNuke's other team members with editor permissions. At pnLanguages, you chiefly only have to deal with me. :) And I'm a nice guy, I promise you. :)
When I talk about "editing", I mean I'll correct grammar and spelling, but I'll also read your articles, and -- where I see a need -- feed back thoughts and questions for you to further polish your content. My main criterion is whether there is some logical validity or standpoint for what's being said.
You'll get full credit for your articles, and the editing process will be a two-way interaction. The final draft will only be submitted for publication with your complete approval.
Don't worry, I'm a free-thinking, cooperative, open-minded person, and I believe that putting contrasting opinions face to face is a great way of opening-up constructive debate. I'm not talking about trying to direct your thoughts, just possibly inviting you to express them and form them more fully, if such seems to be needed. Even if those ideas don't match my own. You can trust me to be objective and detached. My main criterion is whether there is some logical validity or standpoint for what's being said.
Most important, though, is to be courteous and measured in what you say. No "personal attacks". :) And if you talk about a "problem or issue", then try suggesting some "solutions and answers". Constructive criticism is a healthy thing.
Got something to say? OK, organize your thoughts and put it down in writing! Let's all read it!
For a good model of what I feel is a well-constructed article, take a look at Olaf Fichtner's contribution about the PostNuke language system on pnNews (Olaf's article can be seen here). I'm firmly hoping that Olaf is going to be following-up on that paper. But we need to see others from other people, too.
Really hoping to hear back from you. :)
David at PostNuke dot com :

Generated on September 22, 2005.

PostNuke and its future language system: a translator's viewpoint   (News)

1 What this article is about, and why I'm writing it
PostNuke has developed quite a lot since it forked from PHP-Nuke; many changes have already been implemented in 0.7.6.0, and many more will be reflected in 0.8. However, compared with other parts of the core code, the language system hasn't changed much. And what has changed recently might not always have been a good idea.
Most of the development work on PostNuke is done by speakers of European languages (predominantly English and German, but also Danish, French and Spanish, to name but some). Speakers of those languages might not be aware of the differences between their mother tongue and some of the more-exotic but widely-spoken languages in the world. Since I spend quite a bit of my time applying different languages, I'd like to show a few problems and make a few suggestions that perhaps could be further discussed.
I have looked through the PostNuke language files before, but it was only when I, together with two students, attempted to translate them into Chinese that we noticed how difficult a task that can be. Parts of PostNuke 0.7.6.0 actually cannot be translated meaningfully into Chinese or Japanese anymore.
When I was working on the translation, I happened to "complain" in the pnLanguages forum on PostNuke's NOC (Network Operations Center) about a few of the problems, and was answered by David Nelson of the pnLanguages team. He suggested I should put all my "frustration" (well, it isn't that serious, but some of the problems really are…) into an article, which is what I'm doing right here and now.
2 Current problems with PostNuke's language system
There is a thread [1] on the PostNuke forums, started by ColdRolledSteel, in which he raised a number of very important points. It was that thread that actually made me start thinking about the shortcomings of the current language system, and what the solutions might be.
If you read further on in that thread, you will find comments about 0.7.6.0. It's a long discussion, but if you're interested in PostNuke localization then I recommend you to read all of it, since many serious problems are mentioned. Good-quality localization into some languages may actually become very difficult unless the language system is overhauled.
Most PostNuke enthusiasts know that PostNuke forked from PHP-Nuke. With PHP-Nuke, not only do you have to pay to get access to the latest version of a GPLed software, but also many people would probably agree that there can be significant changes from version to version.
Not all of those changes may be approved-of by many, since the line of development of PHP-Nuke is decided by just one person: Francesco Burzi. You can read many posts in the PostNuke forums about the problems the PostNuke developers have had in fixing problems caused by PHP-Nuke code leftovers.
What seems to be forgotten is that, unfortunately, one of the legacies is the way PostNuke handles languages.
Here is a summary of problems raised in the above-mentioned thread and other threads, that I encountered:
too many files;
too many phrases used multiple times;
language files are hard to handle;
separation of grammatical particles can make it impossible to provide a good translation in some languages.
Again, please read the above-mentioned thread [1].
3 Suggestions
3.1 Files and folders
3.1.1 Simple structure instead of chaos
Instead of having one language folder for each language in every module folder, why not have just one central "language" folder with just one file for each language? The file could be an XML file, containing all the strings needed by the core system. If a new module is installed, the installation procedure could copy all needed variables and strings into that file. When a module is uninstalled, the de-installation procedure would then be responsible for removing those strings from the language file (in the same way that tables are created and deleted at present).
3.1.2 Why the current language system is chaotic
Does anyone know how many variables and strings are used in the core system alone? Maybe some of the developers will know (though I seriously doubt it); but, certainly, nobody who tries to produce a language pack knows. What they will soon learn, however, is that many strings show up more than once.
If I recall correctly, there are also a few different variables for the same purpose/string. All this is definitely not very motivating for those who want to translate PostNuke into another language. Plus, the translator may well not remember the exact phrase he/she used the last time this string was encountered a few modules ago. Just as there is often more than one way to express something, there is frequently also more than one way to translate a phrase. So, if you consider consistency in translation to be important, the present language system does not help achieve that.
It would also help if the above-proposed single language file could be processed by software. I mean, the year is 2005 and even translators are using computers these days. Every step that makes administering and translating strings easier will lead to better productivity, higher-quality output and availability in more languages. A translation tool (something like pnDefineMachine) should be included in the PostNuke core distribution, and should allow translation of core and third-party modules. To give translators more flexibility in working, it would be ideal if all identified strings could be exported to a file so that they can be worked on using other software and then re-imported.
3.2 Strings and variables
3.2.1 Simple, unique, short and distinct
All strings should be revised to check whether they are really necessary. They should also be as short and as clear as possible. If one single file were used, it would be easy to eliminate duplicate strings and variables.
Any variable output from the PostNuke code (a number, a user name, etc.) for incorporation within a natural language string should be included in the language file. It should also be possible to choose where in the string the variable is positioned.
In the past, developers often just created two language "defines" and the translator was left to guess what was missing between the two. Sometimes, due to the ordering of "defines" within the language file, the translator also had to realize that two "defines" were indeed used in conjunction, because they did not follow in succession. In such cases, some burrowing through software code files was needed for verification and understanding.
This problem is slowly being addressed. The age check string from the NewUser module's global.php language file is a good example. This "define" allows for free placement of $minage within the translated string:

define('_MUSTBE','You must be '.$minage.' or over, or have parental permission to register for an account on this site.');
All strings should compose a "meaningful phrase". The best would be a complete sentence, but in some cases single words or short phrases may be OK or are unavoidable. Just please, please don't separate any prepositions or similar grammatical particles.
3.2.2 Why translating current strings can be really frustrating
Imagine you tell someone, "Here, this is what you've got to translate. Some strings will show up twice; but some occur three, four or even five times. No, I can't tell you which strings. Just translate it. Oh, and you won't be getting any clues about what some of the cryptic, enigmatic phrases mean, nor where to find them on the site." How motivated do you think that person will be?
How happy will the translator or a webmaster be when he/she encounters something like the "define" below (from the Xanthia module's admin.php language file)?
define('_XA_CONFIGINFO','Simply enter the new value in the text area and click Commit, the changes will take effect immediately. Unfortunately, the ability to create and delete general configurations has been removed, as it was never fully implemented and now never will be.');
Translating a language pack should mean translating the user interface, not the story of PostNuke's life – that's something to include in documentation, no?
In addition, it would be helpful if developers do their best to make strings clear and understandable! This one that used to be in the Downloads module's global.php (now rectified) could phase a native English speaker, let alone someone else: "Let main vote summary decimal out to n places".
The general lack of informative and explanatory comments in the core code files and language files does not make a translator's work easy.
And dealing with problems is made harder when strings occur multiple times.
I know the code is advancing with every new version of PostNuke. But, unfortunately, this is not true from a linguistic point of view. 0.7.6.0 is a step backwards, although it was probably meant to take the language system forwards.
Let's look at some examples involving a number of languages: English, German, Chinese and Japanese, but some others are mentioned as well.
Many native speakers of a language may not be very familiar with all the theory behind their mother tongue's grammar. They may have had to learn it at school, but now they just use it naturally. For localization however, it may be necessary to dive into all that theory a bit.
The English language (along with many others) uses prepositions ("on", "in", "behind"...). But some languages don't have them. Hungarian, Finnish and Japanese use postpositions instead. That's right, they come after the object, not before it. In Chinese, there are prepositions, but many phrases use constructions similar to postpositions.
Let's look at the problems that this can cause. Let's take this sentence: "The book is on the table".
"The" is a definite article; "book" is a noun; "is" is a verb; "on" is a preposition; "the" is a definite article; and "table" is a noun.
"The book is on the table" is a simple sentence which, in German, translates to "Das Buch ist auf dem Tisch." It's hard to deny that German and English are somehow related.
But the same cannot be said of Japanese. "Book" in Japanese is "hon", and "table" is "tsukue". Since a book is not a living creature, the verb used will be "aru" or, in neutral politeness, "arimasu".
But how about "on"? The correct word here is "ue", but you can't just use it that way. "Ue" means "top", "above"; so, in Japanese, you have to say "on top of". "Of" would be "no"; "on top of" becomes "no ue ni" ("inside the top of something", so to speak). Did you notice the different order? Now here's the whole sentence: "Hon wa tsukue no ue ni arimasu." ("Wa" is just a particle marking a sentence's topic.)
While "book", as subject, is still at the beginning of the sentence, it is followed immediately after by the object, "table", then the postposition, and finally the predicate. Now imagine what incorrect or incomprehensible Japanese would be displayed if prepositions and other words for a given phrase or sentence are spread within separate "defines" in the language files. If you read through the forum thread mentioned at the beginning of this article, you will also find a few examples for Finnish. If you "turn the table" and try to make an English sentence translated word-for-word from the Japanese sentence structure, you would get something like "book table on is".
This is another reason why variables that will be processed by the PHP code, and rendered in an output form to be incorporated in the displayed string, should be included in the "define" for that string in the language files.
Let's take another simple example: in English (and many other languages), we say "A of B", as in the phrase "3 of 10 users". But in Japanese, it is "B no A" (and "B de A" in Chinese). So, simplification is a good thing but needs to be done the proper way, otherwise important parts of PostNuke could be practically unusable in a few languages in which the potential user base might be enormous [2]. Do you think a Chinese or Japanese would like a portal that tells him "10 of 3 users are currently on-line"?
By the way, did you notice that there are no articles in the Japanese example? English has one definite article (effectively one gender), French has two (for the masculine and feiminine genders) and German three (for the masculine, feminine and neuter genders) , so there are big differences between languages even for such an elementary point of grammar. But then consider the treatment of number and quantity in different languages: anyone who has examined the language files will know that there are different strings for "day" and "days", since singular and plural exist in English, German and many other languages. However, this isn't true for Chinese: "day" is "tian" in Chinese, and no matter whether you're talking about one, two or a million days, it's still "tian".
3.3 What we can do
3.3.1 Where we really can simplify and standardize
We could create standard "interfaces" for both code (variables) and strings. Since, in the system discussed herein, we would already have only one file, we could establish a list of standard actions like "delete", "create", "submit", etc. This list should be extendible, so that module authors can add any "special" actions for their module (although it would be nice if those "special" actions, too, could be managed by the core development team, otherwise duplication is likely to occur once again). But when already-available actions are used, the module developer would just use the existing variables in their code, and wouldn't have to worry about defining the corresponding strings, since they would already be available in the core "library". Obviously, that implies the existence of a good developer's guide that gives module and block developers proper information about the PostNuke programming API.
3.3.2 Separate what can be separated
So far, we have been advocating the use of language "defines" that contain complete phrases and sentences, incorporating any necessary variables (or, at least, place-holders for variables) for which literal values will be supplied by PHP. As from 0.7.6.0, the developers started to separate prepositions in the core language files. I just tried to show that this may not be a good move, but let's see what we actually can separate out.
It is not a good idea to strip grammatical particles, since grammar can be very different from language to language, and those particles are precisely that: particles. What we always need in order to properly construe a meaning is a semantic unit that conveys enough useful information to allow the receiver to understand the intended sense.
Let me explain this with the above book example: Someone tells you that the book is on the table. However, since a tram was passing by, or you were just distracted by a pretty woman or you were simply asleep, you didn't clearly understand all of it; so you ask that person to tell you the same thing again.
Now, that person may think you are a foreigner and don't understand much English, so he may think "let's make it simple for that poor fellow" and just tells you, "Book". Nice. Yes, I know what a book is. But does he want me to write a book, buy you a book or did I perhaps completely misunderstand and he wants me to book him on a flight to Alaska?
He repeats, "The book." Nice. Now at least I know that he doesn't want to go to Alaska. "Table," he adds. With much imagination, I might start to guess now that there is a table with a book on it. If I had heard the complete phrase just once more, there wouldn't have been any problem.
But how about single words then? In English, there is something called the "imperative mood" for its verbs. The verb itself does not change, since there is no flection. So, at least in English, you don't see a difference between the regular form of a verb and its imperative mood. However, you can shout "Shoot!" or "Fire!" and the receiver of that order will know what to do.
Not every language will use a verb to express this. German will use a noun, "Feuer". Japanese is closer to English this time, it also uses a verb: "Ute" is the imperative form of "utsu", which actually means "to beat". So, what we can strip are units that can stand alone semantically, and actions are one such thing.
It may happen that such an action is not always a single word in every language, but to organize them in a list and to standardize them system-wide would help to create a more consistent user interface. It would be a bit like function calls in a code library, but for strings.
3.4 Error messages
3.4.1 Error codes in one list
It is common in software design to assign codes to errors and to display a message corresponding to the code. As with the actions discussed above, we could create a list of error messages shared in common by any module and block throughout PostNuke.
3.4.2 It says "Xxx". What should I do?
I think everyone has seen "a few" posts in the PostNuke forums asking what this error or that error means. With the above method, a given error would produce the same message throughout the whole system. It would probably even be possible to provide a list of possible causes for each error, so that users can solve their problems more easily. But again, who would want to maintain a list of causes, if every module comes with its own error messages, each of which is phrased differently even though it pertains to what is effectively the same error?
Obviously, because a module often provides some special functionality that does not exist in other modules, there will probably be some module-specific errors. This problem could be solved by asking every module developer to apply for a block of error codes for that module. Again, the installation procedure of that module would have to take care of copying that block of "defines" and strings into the main language file.
3.5 Expand your horizon
PostNuke is GPL software, and so are many other content management systems [3] and portals that exist today. If they want to implement really-extensive internationalization [4] of their design, then they face the same problems as PostNuke. Some of their people may have come up with solutions nobody here thought of, so why not look around and see how they solved some of the problems PostNuke has to deal with?
One example could be Drupal [5], which has found a few solutions for language-related [6] problems [7] that could prove useful.
4 Conclusion
This document is far from being complete. It only takes a glance at a few languages: more input is needed from speakers of other languages. Also, the modifications I suggested may not always be the best and there are probably also other improvements that can be made. However, if PostNuke really intends to move towards broad internationalization, then it will be necessary to revise the language system and, possibly, other parts of its design. This article is intended to contribute to a thought process about that.
Obviously, nobody knows all the "features" and "traps" of all languages. That's why the pnLanguages team needs to have members from as many different nationalities and languages as possible, so that we can assemble guidelines that will allow the correct use of any language in which we have a user base.
Localization and translation are now recognized as key issues for the PostNuke project. When it comes to language and internationalization, more liaison between the pnLanguages team and the core development team will be very important.
Relevant links
1. http://forums.postnuke.com/index.php?name=PNphpBB2&file=viewtopic&t=24602
2. http://en.wikipedia.org/wiki/China#Demographics
3. http://www.opensourcecms.com/
4. http://www.debian.org/doc/manuals/intro-i18n/index.en.html#contents
5. http://drupal.org/
6. http://drupal.org/handbook/modules/locale
7. http://drupal.org/node/24593
8. pnLanguages project on PostNuke's NOC

Generated on September 11, 2005.

French 0.760 Package - Pack français pour 0.760   (News)

The pnLanguages Project
and on
The pnFrance Project
----

Suivant la vague des traductions disponibles...

Pack français pour PostNuke disponible sur
Le projet pnLanguage
et sur
Le projet pnFrance

F. Chestnut !
(PostNuke-France.org 2.0 Coming soon !)

Generated on August 29, 2005.

Latest Stable Release Now Available: A Major Step on the Road to 1.0   (News)

Upgrading from Older Versions?

Backup, backup, backup.

Before you upgrade we'd like you to keep in mind much of the core code has been changed. For example, there may be modules, blocks or themes that do not work with this release. So as usual, we recommend you create a test site before upgrading and/or backing up your files and your database. Also, when updating it's a good idea to document which modules work and don't work with the new version so we can help mod devs know the bugs. We suggest you post this information to the forums so module developers will have immediate feedback about which of their modules work with this latest version. Note, if a module is abandoned then you might be able to find a developer who is willing to update it too.

Finally, the upgrade functions have been tested in as many scenarios as possible so you can safely upgrade from any version of

Generated on September 2, 2004.

Official pnlanguages releases first packages   (News)

Generated on June 29, 2004.

PostNuke Team Expands   (News)

Pack Co-ordinator) runs the "pnLanguages" project at the NOC. Murilo Pinto assisting in this project. More volunteers to follow.

On the communications front we now have a new co-ordinator, Franz Skaaning aka lexebus of LEXeBus.NET, we hope he can continue our communications revolution that was so necessary. He has professional experience in this area so he is well qualified for the job.

We would like to welcome Senne Van Baelen AKA donkeybe as a new forum moderator.

We have added more developers to the fold: Devin Hayes aka InvalidResponse, Franky Chestnut and Chris Miller aka r3ap3r.

Devin is an active module developer and has release scores of well coded modules into the community. Franky Chestnut from PNConcept is also another fantastic programmer, and Chris Miller is noted for his bug fixes to PostNuke. We are very proud to have these people on the development team.

This is a very exciting time at PostNuke with so many improvements in every area designed to ultimately benefit you, the pnUser

Generated on May 30, 2004.

Brazilian Portuguese for 0.726 with over 60 modules!   (News)

supposed to "hit and run", because there might be some files which are heavily hacked -- yes, you can do that to translations, too :-)

That's because I used for quite some time pncUserHack (affecting NS-User, NS-NewUser and NS-Your_Account) and some News hacks. Also, Extended Topics and AT Lite Blocks might have different defines. But, anyway, that won't stop your site from working, of course. And bear with me, as this is a one man job.

But, please, send me your patches, so I can clean it up and release a FULL CORE COMPATIBLE TUpInUKIM, ok?

Here's the listing of modules included:
******************
* Módulos (63) *
******************
advanced_polls
All_Stories
Archive
Autolinks
Blocks
Censor
ChangePassword
ContentExpress
Credits
Downloads
dq_helpdesk
Encyclopedia
FeedBack
feproc
fetax
FormExpress
legal
MailBag
Members_List
Messages
Modules
News
NS-AddStory
NS-Admin
NS-Admin_Messages
NS-Banners
NS-Comments
NS-Ephemerids
NS-Groups
NS-Languages
NS-LostPassword
NS-MailUsers
NS-NewUser
NS-NewUser*
NS-Past_Nuke
NS-Referers
NS-Settings
NS-User*
NS-Your_Account*
pagesetter
Permissions
photoshare
phpBB_14
pn_bbclick
pn_bbcode
pn_bbsmile
pnTresMailer
PostCalendar
Quotes
Ratings
Recommend_Us
Search
seminars
shortnews
Stats
Topics*
UpDownload
Web_Links
xuser
* => modules duplicated in the pack due to hacks:
pncUserHack
ExtendedTopics

******************
* Blocks  (28) *
******************
admin.php
banners.php
big.php
category.php
emldaonline.php
ephem.php
error.php
finclude.php
fxp.php
i-featured_article.php
linklist.php
login.php
menu.php
online.php
past.php
phpBB_14.php
phplive.php
poll.php
progress.php
radio.php
recent_and_top_news.php
rss.php
rss2.php
stories.php
thelang.php
topic.php
user.php
whatsnews.php


Download link: http://prdownloads.sf.net/pnlanguages/pnlanguages-x_brazilian_portuguese-0726-tupinukim-A-beta.zip?download
Release notes (in Portuguese, pretty much the above info): https://sf.net/project/shownotes.php?release_id=239437
Project page: https://sf.net/projects/pnlanguages

Generated on May 20, 2004.

PostNuke Language Package Project   (News)

https://sourceforge.net/projects/pnlanguages/

If you know of a language package that has not been included in this project or would like to add or update one please let me know. Each language package has the URL of it's origin under "release notes". As time permits we will add more credits.

If you are the maintainer of one of these language packages and would like to become a project admin please email me at webmaster@pnapi.com

please send the following information so that we may properly archive these language packs.

1) URL where the package may be downloaded.
2) precise name of package file
3) PostNuke version Number
4) Date of release.
5) Person(s) making the release.
6) Contact info.

Thank You
Mediatech

Generated on April 3, 2003.

Page 1 / 2 (1 - 10 of 11 Total)