General texts are stored in the files under the language folder. The naming of those language files follows the convention "lang-languagename.php". Thus, english texts are held in
language/lang-english.php, chinese ones in language/lang-chinese.php etc. All you have to do to change a text, is edit the aproppriate file for your language with a decent text editor (see also Chapter 11).
For example, to change the text that is displayed besides the Search button ("Search" for the english language), open language/lang-english.php with a decent text editor and find the line that contains the text:
define("_SEARCH","Search");
This is a PHP instruction that tells the PHP interpreter to define the constant _SEARCH as the text string "Search". Thus,
whatever you put in the text string will be the content of the _SEARCH constant. The developers (at least in an ideal world) will only use constants (and database-driven, dynamic information) for
their texts, so that you only need to do your changes at one place to be valid everywhere. To change the search text to "Search my homepage", you thus need to change the above line to
define("_SEARCH","Search my homepage");
It is in this manner that internationalization of PHP-Nuke takes place, by the way. People who want to translate PHP-Nuke to their
language, get a fresh copy of language/lang-english.php and start translating the text strings in the "define" directives, then send the lang-newlanguage.php file to phpnuke.org for inclusion in the next release.
HTML code in text constants
You are not confined to text, when you change the texts in PHP-Nuke's language files. This may sound paradoxical, but if you think that the language files are just usual PHP files that define some constants, then you will see that nothing really prevents you from "abusing" their purpose and mixing them with...HTML code, for example.
Thus it is perfectly legal to change:
define("_WRITES","writes");
to:
define("_WRITES"," writes");
In this case, we entered a non-breaking space before the translation of the _WRITES constant. This is because we noticed that a space was missing before the "writes" in the "user writes" string
that is printed next to an article in the news. Instead of correcting the code in the News module, we opted for the quick'n dirty way. It's not recommended, because it mangles user-supplied data with
code - but it is nonetheless possible, see Posting Articles or Story.