langdoc.php - a tool for online docs and help files translation
2005-02-11 15:10:55 1CzbVT-000HMe-0i <= firstname.lastname@example.org H=adsl215151.vnet.hu (golem.devel.mindworks.hu) [62.77.215The letter was:
.151] P=esmtp S=1618 email@example.com
2005-02-11 15:10:57 1CzbVT-000HMe-0i => firstname.lastname@example.org R=dnslookup T=remote_smtp H=moodle.org [18.104.22.168] X=TLSv1:AES
2005-02-11 15:10:57 1CzbVT-000HMe-0i Completed
Hello Martin, Near half year ago I've sent you a letter about Hungarian translation of Moodle but you haven't answered me. I try to actualize and organize the translation, but I should get a CVS account (aries69 at SF) to update the language files. Can you help me? Bests,
I'd like to ask you - should I care about some CVS tags of langdoc.php or is this Martin's job? I've read developer manual but being still CVS beginner I don't understand very much how langdoc.php will became part of official (pre)release.
Thanks for any explanation.
I just changed the (!) for untranslated files in *** for visability, but I might as wel need new glasses
I found the script create a new empty file when I choose a file not existing from the dropdown list, no matter I press save button or not. If I haven't write anything, I will have to delete the empty file by hand sometime later or it prevent the English one being displayed. Maybe it's better not save the empty file.
I've given you CVS access to it so make fixes there! Thanks!
Many, many thanks for this tool !
May I suggest to the translators that ANY file in the help folder begins with this string on the first line:
<!-- Version: $Id$ -->
and to set the $filetemplate var in langdoc.php accordingly by default. This way we could know rapidly when the last changes were made. It could be very useful
Thanks again !
Nicolas, french translator
Thanks a lot for this script. It's great.
I change it a little bit and added editor support. It is much easier for other translators to do the translation in editor rather then in HTML.
The help files must remain free of all styles so that they can be used in different contexts.
Anyway this script helps us to move more quickly and other people may find it useful as well. We will make sure all the doc/help files are clean from any extra code.
I don't think so - IMHO it is not a good idea to allow wysiwyg in langdoc.php (for the same reasons as Martin noted). And I don't think that HTML editor would encourage other people to translate help - at least not in my country But maybe you will find a way how to keep the code clean...
And the last note: my experiences show me it is not necessary to have whole help and doc translated. Users don't read it anyway - they always try to find their own solutions
I like this one "Users don't read it anyway" .
About the way to keep it clean. We are copying the original html to translation box, changing it to HTML and replacing the English text with our translation. it works pretty well.
Our problem is that several translation team members are not familiar with HTML and they prefer to work in editor.
It doesn't take long to learn what the HTML codes do, and they don't need to change them anyway, just avoid them.
But I have a problem:
When I translate a page that includes some php script, it is
replaced by the result of the script.
For example, in the Installation FAQ (faq.html) there is a place
where it is suggested that the user writes the script
<?PHP phpinfo() ?>
to find out what PHP version is running. When I save the changes
to my translation, that line is replaced by the whole outpout
from that command (that does not happen if you edit the file
using the file module).
Thanks for your report! The important question has arised: are <? <php and <PHP tags allowed to be included in help and doc files? Are they needed somewhere? The current version of langdoc assumes the translator to be responsible for the HTML code so it allows put these tags. But we can let some filters to be applied before saving the code.
One has got possibility to include these tags with & lt;php syntax (how is it called - HTML entities?) so I would prefer not to filter anything and trust the translators...
I did not explain the problem correctly. The current bug is:
when the user first translates the file, he will use entities
< and > when he wants to refer to some tag.
If he tries to edit the translated file again, the
< and > entities in the original file are shown
as < and > in the translation form.
When the user saves the file, even if no changes were done, the
file will be spoiled (the literal tags that were initially
written correctly using entities will be transformed into real tags, causing trouble).
Also. I have not checked it yet, but a single backslash in the original
file should not become a double backslash when one saves a new
version of the file (that was a bug that we already fixed in
the file module).
to look at any of the mods.html files, for instance help/hotpot/mods.html, using langdoc.php
You can compare what langdoc.php shows you with the real content
of the file:
Due to that bug, there are several translated files,
in several languages, which are wrong. For instance, look at the
Dutch translation of the file above (no need to know Dutch;
just compare the URL in the first line):
The file I send in attachment solves the bug.
So it's the editor causing trouble. Thanks for pointing that out.
I've found about 18 affected files over all language packs in ja/ja_utf8, lt and sv.
I'll fix them asap
> ja/ja_utf8, lt and sv
Good job, Koen. You only missed the Finish language (fi) where
instead of "localhost" you should look for occurrances of
"http://moodlepalvelut.fi" which most be the server where
the Finish team has been running langdoc.php