PostNuke

Site search

Search results

Number of hits: 60

A Warm Welcome to Our Newest Member, Mateo Tibaquirá Palacios   (News)

Welcome Mateo, tell us a little about yourself. Who are you,
where are you from, and what do you do?
My complete name is Néstor Mateo Tibaquirá Palacios, but I prefer to be called Mateo. I'm from Colombia, a very beautiful country with some horrible problems; balanced, eh? I live in Popayán, where I'm finishing Electronic & Telecommunications Engineer Studies with an emphasis in Telematics (Information and Communications Technology). I chose Telematics because I like to program. Growing up, I did not have a computer, and from the distance I hated the idea of using a command line console. Now, it's different; I love my Ubuntu with the Yakuake console; and Eclipse PDT rocks!
At the University, I discovered that I had sufficient skills to write software. I began programming in C++ and Java some time ag

Generated on January 26, 2008.

Looking for Documenation Project Team Members   (News)

Potential candidates check list:



A well-rounded understand of PostNuke. You need not be an expert in
everything PostNuke, but you should be able to effectively administer, adapt
and modify a PostNuke site.


Able to reasonably read and write in English, as far as it pertains to
PostNuke documentation writing. The key is reasonable; You do not have to
master English writing, as content is more important over style.
Contributing author's English will be edited for clear and concise grammar
and usage.


Able to work with a team. This may mean adjusting personal styles and
viewpoints to the teams objectives. This also means to possess the ability
to collaborate and construct ideas as a group member.


Must have the time to work on such an extensive project. Yes, we offer
flexible hours.


Must be able to commit. Must be willing to commit. Also commitment is
essential. And before I forget, we need someone who is going to commit to
this project.



Benefits:



Long hours and no pay


Getting to contribute to the PostNuke project


Having your name associated with PostNuke (Hey, you can put it on your
resume)


Development of friendship and camaraderie




Are you still interested? Well, if you are please send me a Private Message
here
on this site.


Include:



Your name and PostNuke Handle (Nickname)


Experience with PostNuke and related


Your motivation for this project


The amount of time you can give per week. Average.


Any relevant information, you feel we should know about.


Any spacial skills (related to this project) i.e. Technical Writer




Even though, we would like to accept all candidates to this project, we
cannot. It is our intention to keep this project small enough to be
manageable, yet large enough to be effective. I will be selecting only a few
for final review and selection by the Steering Committee. Thank you in advance
for your consideration to this project.



David Pahl -- Documentation Project Lead

Generated on October 6, 2007.

3 Bugs to go: Postnuke .8 close to Release Candidate   (News)

prioritize them and only remove the class 4 and 5 bugs. Mark West and Jørn Wildt have been busy on closing one after another. Until yesterday there was only one remaining, which Robert Gasch promised to close. But now Jørn found 2 new ones: Bugtracker

Performance
While waiting for Robert to finalize the debugging of the categories module, Jørn and Mark checked .8 for its performance and found only few major flaws which have been removed in the meantime. As far as I understood Jørn's tests a blank Postnuke .8 doesn't contain more SQL-statements as inevitably needed and though calling a load of PHP functions performs quite well.

If you are able to test Postnuke on different environments - please do so and report your findings.

Language Files
David Nelson had to take a break from overhauling the English language files. But AFAIK he picked up work again and will be done soon.

After finishing the language files and closing all remaining major bugs the team will release a first release candidate.

The Wiki needs input!
If you want to help and you are neither a coder nor a templater you can help us with the documentation! Not everything in .8 i

Generated on June 6, 2007.

pnFlashGames Vulnerability   (News)

Thanks to Devin Hayes (aka InvalidResponce) for the information. He also posted a solution. See this thread in the forums. I have modifed the file and also made it available here. This patch is unoffical and comes with no warranty or support.
Anyone, using pnFlashGames should secure their websites.
Happy PostNuking,
David Pahl (aka AmmoDump)

Generated on May 3, 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.

Spam Protection   (News)

module of its own. It's not yet ready, but I hope it will be soon available for inclusion into guestbooks, comments, forums aso.

A module that Mark West released yesterday is "Bad Behaviour". "Bad Behavior is a PHP-based solution for blocking link spam and the robots which deliver it.

Bad Behavior complements other link spam solutions by acting as a gatekeeper, preventing spammers from ever delivering their junk, and in many cases, from ever reading your site in the first place. This keeps your site’s load down, makes your site logs cleaner, and can help prevent denial of service conditions caused by spammers." -- Bad Behaviour Homepage

As you include it into the pnAPI.php at earliest possible position, it stops Postnuke loading its higher functions when it detects a spam bot access. This means that all detected access cause only little traffic.

IMHO a combination of Akismet and Bad Behaviour will reduce the amout of spam on our sites without building barriers also for normal users. But we will have to live with spam, if we want to keep up our sites.

Links

Bad Behaviour Homepage
Bad Behaviour Download
Akismet
Support for both Bad Behaviour and Akismet modules.

Generated on March 8, 2007.

PostNuke Security Advisory 2005-5   (News)

VULNERABILTIES
- Anonymous users can add comments without being required to log in.

SOLUTION
It is recommended that all admins upgrade to PostNuke CMS Platinum
Edition 0.761

The hash sums for the PostNuke CMS Platinum Edition 0.761 are:

MD5
4b76e09c507db0224d34fc448e7efb91 PostNuke-0.761.tar.gz
c4090097b26caa38115540e24378e9b4 PostNuke-0.761.zip

SHA1
b69d9bfabb5c8641e4b5dd9e9ee6f5803d86c41d PostNuke-0.761.tar.gz
79869b9a7003ac9046788cebad23135f68eef648 PostNuke-0.761.zip

Download from http://downloads.postnuke.com

CREDITS
The exploit was originally discovered by Devin Hayes (InvalidResponse)

Drak [drak]
PostNuke CMS Development Team

Generated on September 28, 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.

Interview: Steffen Voss   (News)

What is your real-life job?

I'm a student and going to be an Englisch/Geography teacher. But I also have a job at the university (http://www.gis.uni-kiel.de) and I help the local youth council with their websites (e.g. http://www.balticsea-youth.org).

Tell me about your postnuke "career". (Why do you prefer Postnuke over other CMS?)

When I worked for a bigger German company I had to maintain the intranet. They used static pages until then but I had heard something about CMS and took a look at Postnuke and was overwhelmed. It did almost everything I needed. So I convinced the head of department to use Postnuke and it became my first Postnuke project. Only little later, friends of mine wanted to relaunch their local website (http://www.kiel4kiel.de) so I helped them to implement that with Postnuke.

Postnuke.de was the first contact I had with the Postnuke community, but as the site was a bit messy I offered my help. The webmaster ranted a lot but never let me do anything but post news and forum posts. Little by little I realized that this endeavor what pointless and started looking for like-minded people in Germany and finally found http://www.post-nuke.net. A reservation for the shunned. Larsneo and others had similar experiences with postnuke.de and built up their own community.

By and by we created a German documentation and had more and more people joining us. This year we established a German foundation and organized the first international Postnuke meeting. So things are going well. :-D

What is your task in within pnCore?

I don't have an official function. I do interview, comment and try to keep contact to the core/module devs and to allude them to what the others are doing. "Networking" I think you can call it.

When did you start programming for PostNuke?

I started programming for Postnuke during the Kiel4kiel.de-project - a module called tinyraffle which you find in the noc in a not finished state. I don't need it anymore - so feel free to adopt it ;-)

What is your work like?

As I said - I read and write a lot in the German forum, I mail with devs and try to keep them together and strengthen the company.

What is the biggest difficulty in your work?

It's often hard to promote Postnuke, because of the special communication strategy the project management embarks. There are a lot of nice people working very hard on the future of Postnuke, but the average user only hears about that when a new release comes.

Which route will Postnuke in your opinion go in the future?

The Postnuke core is already far away from PHPNuke but there are still serious lacks on the user side - content handling hasn't improved since PHPNuke - disregarding modules like pnCommerce, Photoshare, Pagesetter aso. .8 will bring the new and for the time being final core. Next thing should be a concentration on the content side of the project. This is what gives new users a good first impression - not a well written source code. Sad but true ;-)

What is the weakest/strongest point in PostNuke?

The weakest point is the name - The general public always mistakes Postnuke for PHPNuke. The strongest point is the great community.

Are you also working on modules?

Yes and no: I released pnAmazon - a module that allows you to include Amazon product-data into you Pagesetter publications using Amazon Webservices. But as it now does all I need, motivation is little to develop it any further.

Internally I work on a module that does almost the same as pnAmazon with an information system that almost every German university uses (uniVIS) - It allows you to include data such as addresses, lectures aso. directly from the central information system into your page. So the department's page is always as up-to-date as the central system. Maybe I'll release it, when it's more advanced. But I'm still looking for a co-developer for this module.

What features should the Postnuke .8 core have to simplify your work?

pnRender is a killer. I love it. It does all I need, but Xanthia has to become more user friendly.

What should users of your module regard?

I only include things that are either needed by me or very simple to implement - I'm not such a good coder...

Anything else you always wanted to say about Postnuke?

Postnuke has such a big user bases and too few people, who actually work for it. A main issue for the future of Postnuke is IMHO to activate the community and to make it easier for people to add their work to development, support, marketing aso. Even the smallest help is help.

Thank you very much for you time.

My private homepage: http://www.kaffeeringe.de

Generated on December 20, 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.

Page 1 / 6 (1 - 10 of 60 Total)