Warning to non-US citizens, against using the language translation tool in the ver. 2.65 release, because it probably will corrupt your language files, and afterwards you probably will have to read your language files into an editor and manually replace the corruption introduced by the language tool: Making it much easier, faster, less troublesome and less error prone to do the translation in the editor in the first place :-(
When I first started translating phpGedView, we were two persons doing the translations, and in order to avoid problems from unwanted whitespaces, the other guy, Gert Krabsen, decided to use html entities for the special Danish characters. Well, Gert only participated in the first translation, but ever since I've been using html entities.
Starting from the ver. 2.65 release, the language tool now replaces part of html-entities with other html-entities, making sure it all turns out to be absolute nonsense.
I don't know, why Ampersand has to be replace with a html-entity ?
Maybe Ampersand is a dangerous character, but then it makes little sense to replace Ampersand with a html-entity which starts with an Ampersand !
But maybe & can be considered safe ? Well, so can æ ø å Æ Ø Å and all the umlaut entities, and therefore it doesn't improve security to replace them with: æ ø å Æ Ø Å - all that is achieved is to waste the translators time.
Another of my habbits, which used to serve me well, now works against me.
In earlier versions you created havoc if you didn't escape quotation marks in the translations, and therefore I do escape quotation marks in the translated text, but now the tool replaces quotation marks by " but the tool fails to remove the escape character, if a escape character exist !
Another example of contraproductive replacements done by the translation tool:
The text to be translated:
<a href="readme.txt">readme.txt</a>
such a text as above is supposed to be a clickable link.
If translated like this, it still will be clickable and won't create havoc I guess:
<a href=\"readme.txt\">readme.txt</a>
But here again the tool does its own replacements:
Arne,
Doesn't this belong in the high priority bug section?
It's not only annoying, but also very inconvenient at the moment, because we're working hard to get all help-messages properly filled.
Boudewijn.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am sorry about this inconvenience. The reason that this is happening is because of a security patch that replaces all html special characters to all incoming variables. This is a brute force approach that will make the program more secure, but breaks the edit language functionality. I will work to get a fix for this as soon as I can so that you can continue working on the translations.
Thanks,
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Warning to non-US citizens, against using the language translation tool in the ver. 2.65 release, because it probably will corrupt your language files, and afterwards you probably will have to read your language files into an editor and manually replace the corruption introduced by the language tool: Making it much easier, faster, less troublesome and less error prone to do the translation in the editor in the first place :-(
When I first started translating phpGedView, we were two persons doing the translations, and in order to avoid problems from unwanted whitespaces, the other guy, Gert Krabsen, decided to use html entities for the special Danish characters. Well, Gert only participated in the first translation, but ever since I've been using html entities.
Starting from the ver. 2.65 release, the language tool now replaces part of html-entities with other html-entities, making sure it all turns out to be absolute nonsense.
I don't know, why Ampersand has to be replace with a html-entity ?
Maybe Ampersand is a dangerous character, but then it makes little sense to replace Ampersand with a html-entity which starts with an Ampersand !
But maybe & can be considered safe ? Well, so can æ ø å Æ Ø Å and all the umlaut entities, and therefore it doesn't improve security to replace them with: &aelig; &oslash; &aring; &AElig; &Oslash; &Aring; - all that is achieved is to waste the translators time.
Another of my habbits, which used to serve me well, now works against me.
In earlier versions you created havoc if you didn't escape quotation marks in the translations, and therefore I do escape quotation marks in the translated text, but now the tool replaces quotation marks by " but the tool fails to remove the escape character, if a escape character exist !
Another example of contraproductive replacements done by the translation tool:
The text to be translated:
<a href="readme.txt">readme.txt</a>
such a text as above is supposed to be a clickable link.
If translated like this, it still will be clickable and won't create havoc I guess:
<a href=\"readme.txt\">readme.txt</a>
But here again the tool does its own replacements:
<a href=\"readme.txt\">readme.txt</a>
making sure, that the link isn't clickable after all, I guess ?
And, when introducing such drastic changes it probably wouldn't hurt to much, to tell it to the translators in advance.
best regard
Arne
Arne,
Doesn't this belong in the high priority bug section?
It's not only annoying, but also very inconvenient at the moment, because we're working hard to get all help-messages properly filled.
Boudewijn.
Sorry... I just noticed it already is!
Arne and everyone,
I am sorry about this inconvenience. The reason that this is happening is because of a security patch that replaces all html special characters to all incoming variables. This is a brute force approach that will make the program more secure, but breaks the edit language functionality. I will work to get a fix for this as soon as I can so that you can continue working on the translations.
Thanks,
--John
Hi people,
I come a little late to the discussion.
I think for the moment it's the best to stop translating the help_txt.xx.php !!
Translating the other files can be done, since there are not that may variables.
The Help text however have variables with contents that are rather long, and it is completely not workable with the results of a translation.
If you succeed to translate a long sentence you are very lucky, but what if you want to change something later??
At the moment I am about halfway to add ?? to the pages and to add some English text to it.
So, I think it's better to wait with translating the help until John has found a solution for us.
Best regards,
Jans
I have fixed the language editor and put a patch in the patches section here:
https://sourceforge.net/tracker/index.php?func=detail&aid=877007&group_id=55456&atid=477081
Thanks,
--John
Hi John,
thanks,
Arne