On a new server with Debian Jessie (8), Apache 2.4, Perl 5.25.1 and CGI
4.28 I'm getting double-decoded namespaces. An Umlaut will thus turn
into an undisplayable character (a questionmark in a black diamond).
Decoding of path_info was necessary on my old server with Debian
Wheezy (7), Apache 2.2, Perl 5.14.2 and CGI 3.52.
If you're still in the unfortunate situation, you can copy the old
implementation of NamespacesInitVariables into your config file.
As we derive a lot of filenames from strings in UTF-8 encoded files, we
need to make sure that any filename that might might be set by a user –
including all the filenames containing a directory deriving from
$DataDir – are passed through utf8::encode. That is, every character
gets replaced with a sequence of one or more characters that represent
the individual bytes of the character and the UTF8 flag is turned off.
In other words, -d $DataDir might not work if $DataDir contains a UTF-8
encoded string. The solution is to use the following replacements:
-f $name IsFile($name)
-e $name IsFile($name)
-d $name IsDir($name)
(stat($name))[9] Modified($name)
-M $name $Now - Modified($name)
-z $name ZeroSize($name)
unlink $name Unlink($name)
mkdir $name CreateDir($name)
rmdir $name RemoveDir($name)
(Using IsFile for -e is probably not ideal?)
If you don’t, and Oddmuse gets used with Mojolicious, and you use the
Namespaces Extension, and a namespace contains non-ASCII characters such
as ä, ö, or ü, these characters will end up as part of $DataDir and
trigger the problem.
I also wonder whether we should be using some other Perl library.
If you're accept-language settings included something for which no file
exists (such as "de-ch"), then the test for the file would
succeed (testing for the existence of "$LoadLanguageDir/") even though
no actual file will be loaded. This is fixed. Also: implemented actual
testing.
It seems like it is operating on url-encoded strings, so all we have to
do is to decode it. This, however, does not mean that we should print
decoded strings. ‘href’ attribute still has to be encoded (or so it seems).
It seems like oddtrans does not pick up the strings with double quotes?
It's weird, but it does not matter anyway, because we will switch to gettext
sooner or later.
This file has to be regenerated periodically, Alexine will do that.
Also, these long one-liners have to be separated into scripts.
I am deleting this file because I'm not willing to update it.
This is a general revision of the current file, and a massive upgrade
from the last date (2002). Some sentences have been formalized and
have been clarified, including corrections, completing the total of the
translation.