[pmwiki-users] utf inclusion - odd behavior.
pmwiki at celok.de
Tue Feb 13 10:00:26 CST 2007
Am 13.02.2007 um 16:16 schrieb Patrick R. Michaud:
> On Mon, Feb 12, 2007 at 10:57:56PM +0100, Tom Lederer wrote:
>> Am 12.02.2007 um 20:44 schrieb Patrick R. Michaud:
>>>>> BTW, as of 2.2.0-beta31 the UTF-8 version of AsSpaced is now
>>>>> part of the distribution. (As are the other improvements in that
>>>>> recipe. :-)
>>>> ...which were a great help for us utf-8 users if it would work ;)
>>>> Sorry to tell you that it doesn' t seem to work (at least for me).
>>> Are you sure that celok.de is running 2.2.0-beta29 or later?
>> As seen on the pages (below the three vars) i am running 31.
>>> It's also possible that the i18n.zip file is overwriting the
>>> default xlpage-utf-8.php script with the old one -- I need to
>>> fix that next.
>> I reinstalled the 31 version which was indeed 0.3 kB larger, that did
>> not work however....
>> The problem just gor more confusing... i call the utf-8-fix script
>> (as on the PITS page) at the very bottom of my config. If i call
>> include_once('scripts/xlpage-utf-8.php'); instead (at the very same
>> position) it does not work. If i call that BEFORE the XLPage however
>> it works. I thought that the XLPage would call the file already...
> XLPage only calls the xlpage-utf-8.php script if the language page
> (e.g., 'PmWikiDe.XLPage') requests a utf-8 encoding via the
> 'xlpage-i18n' translation.
> The German translation distributed in i18n.tgz is in iso-8859-1
> ('xlpage-i18n' isn't set), thus xlpage-utf-8.php file isn't
> automatically loaded by XLPage(). To get utf-8 in this case
> requires explicitly loading the xlpage-utf-8.php script.
> It's also a good idea to do any language selection fairly early
> in the customization sequence -- before any other recipes are
> loaded -- because some encoding and language settings may affect
> strings created by other recipes.
Which i did of course, btw...let me go over this in a few days when i
have more time...
>>> (Actually, I'm thinking that I will rework the i18n distribution
>>> so that each language is available as its own .zip file.)
>> That is actually an idea i like very much. Maybe you could even
>> consider to make an english i18n file, so i (and maybe some others)
>> don't have to delete the PmWiki.* files everytime i upgrade...
>> meanwhile all functional parts should reside in Site.* files anyway,
> Effectively you're suggesting that PmWiki be distributed without
> any documentation pages at all...?
Uhm... yes, effectively i do.
As a matter of fact, (at least to me) the Documentation is of little
use at least, if it is on my server online.
And as said, with all the functional parts in Site.* the PmWiki Group
basically is the documetation "localized" in English (from my POV).
Of course it is the reference documentation language, and it is of
help to the admin.
Maybe it would not be that much of an (visual, in the meaning of ftp
file browsing) obstacle if the pages would be in group-directories by
default (as you stated earlier, you consider to use by-group storage
To go a step further: Even the functional parts in localized sites
(i.e. PmWikiDe.XLPage etc.) seem to be in the wrong place (for my
taste), as i consider the PmWiki(XX) groups as documentation mainly.
As a naive (as in top off my head) suggestion i would rather put them
in the site group. Like this:
(having the locale code at the beginning makes it easier to sort by
Altogether, I know that this might be a bad idea, as it would
separate the i18n files in many many files, like:
i18n-en.zip (maybe empty)
And that would be a pain to maintain. Yet from the admins point of
view, this would allow to select precisely what fits the need, i.e. i
need russian (and english for most current info) docs, but the pages
should be available in ru, en, de and fr.
-> i18n-ru, i18n-en, i18n-de, i18n-fr, docs-ru and docs-en.
Well, i don't know... just thought i would think out loud, and let
you make the best out of it.
More information about the pmwiki-users