Here is a little script that can help translators to keep their languages up to date. It already helped get the French translation updated :)))
ChangeLog New tool for displaying the translation status.
--- /dev/null 2003-01-30 05:24:37.000000000 -0500 +++ tools/translations_status 2003-09-20 11:34:05.000000000 -0400 @@ -0,0 +1,65 @@ +#!/bin/sh +# Copyright 2003 Dimitire O. Paun +# Simply run it from the root of your wine CVS tree: +# $ tools/tools/translations_status + +MASTER_LANG=En +MASTER_FILES=`find . -name "*$MASTER_LANG.rc"` + +list_translations() +{ + MASTER_FILE=$1 + TRANSLATIONS=`ls ${MASTER_FILE%$MASTER_LANG.rc}??.rc` + for translation in $TRANSLATIONS; do + LANG=`echo "$translation" | sed 's/.*(..).rc/\1/'` + if [ "$LANG" != 'xx' ]; then echo "$LANG"; fi + done +} + +seconds_since_epoch() +{ + FILE="$1" + STATUS="`cvs status $FILE 2>/dev/null | grep 'Working revision:'`" + if ! echo "$STATUS" | grep -q "No entry for"; then + DATE="`echo "$STATUS" | sed 's/[^0-9]*[^ ]* *//'`" + date -d "$DATE" '+%s' + fi +} + + +echo "Legend:" +echo " '.' -- translation appears to be uptodate" +echo " 'x' -- translation needs updating" +echo " '?' -- unknown status (file not under CVS control)" +echo " ' ' -- translation missing" +echo "Master language is $MASTER_LANG" +echo + +ALL_LANGS=`(for file in $MASTER_FILES; do list_translations "$file"; done) | sort -u` + +echo " Module / Language " $ALL_LANGS + +for master in $MASTER_FILES; do + MASTER_TIMESTAMP=`seconds_since_epoch "$master"` + APP=`echo "${master%/*}" | sed 's/..//'` + printf "%25s" "$APP" + for lang in $ALL_LANGS; do + LANG_FILE="${master%$MASTER_LANG.rc}$lang.rc" + if [ -f "$LANG_FILE" ]; then + if [ -z $MASTER_TIMESTAMP ]; then + STATUS="?" + else + LANG_TIMESTAMP=`seconds_since_epoch "$LANG_FILE"` + if [ "$LANG_TIMESTAMP" -lt "$MASTER_TIMESTAMP" ]; then + STATUS="x" + else + STATUS="." + fi + fi + else + STATUS=" " + fi + echo -n " $STATUS " + done + echo +done
Le sam 20/09/2003 à 11:36, Dimitrie O. Paun a écrit :
It was very helpful to locate which ones were out of date (or completely inexistant), but the ones marked '.' weren't all up to date regarding English (see the current commdlg resources for how it's possible).
What is needed is a parser to get at least the structure of the .rc files, to identify the layout of the menus and the ID of the strings, and then compare those between languages. Or something based on that (removing quoted text and comments, then diff? That'd be possible in sh probably).
I can try to whip up something, but it'll be in C (sorry, Perl is akin to Chinese to me for now), so if you all prefer it to be in something else, or can point me to such a tool already existing for Windows resources, it'd be appreciated.
Vincent
Le sam 20/09/2003 à 13:05, Vincent Béron a écrit :
I'm currently developing something along those lines (in sh), and it's coming quite nicely. Also, I've found a Perl book, so I'll try to port it over once the functionnality is there. Should run way faster than the sh stuff.
Vincent
On September 20, 2003 01:05 pm, Vincent Béron wrote:
I think a parser is a bit too fancy. And even if we compare the structure, we still can't tell if the strings are translated. What we need is a bit of help from the translator. They should include a meta comment in the first kilobyte stating what version of the master file they translated.
Something like this:
MASTER: [<lang>] <version>
The <lang> is the 2 letter code of the master language. It is optional, if not present it defaults to English (En).
The <version> is the CVS version of the translated file, like 1.25.
If we don't find this info, the script will default to the current timestamp-based comparison, and it will flag the translation somehow as missing the metainfo so that the translator is aware of the problem.
This also works nicely when the translator forgets to update this info, since in that case the script will still mark the translation out of date, and force the translator to correctly set it. (Also, they can not cheat by setting a high number, as we can easily detect and flag that :)).
Le dim 21/09/2003 à 10:18, Dimitrie O. Paun a écrit :
I think a combination of both is helpful. One in knowing what is uptodate (the MASTER), and one knowing what is not (the attached script, or a variation of).
It's not particularly fast (would need to be ported in Perl, where hashtables exist, for example), but it gets the job done in knowing which resources have the same structure as the master language. Missing lines, menus, stringtables, etc. are also found and reported.
The ww file is needed because my csplit dies with a "Memory exhausted" when used in a pipe following sed for commdlg, but not when used with cat. I'm stomped on that one.
Ideally, it'd be integrated with Make.rules, so it knows where it is and what are the rc files to check.
Comments (especially from those translating parts of Wine)?
Vincent
On September 21, 2003 09:37 pm, Vincent Béron wrote:
Ideally, it'd be integrated with Make.rules, so it knows where it is and what are the rc files to check.
Moreover, the script should also support a switch that would make it generate nice, color HTML, so we can integrate it into the wine_release script, so that when a new release is made, a nice page gets updated on WineHQ as well...
Le dim 21/09/2003 à 21:37, Vincent Béron a écrit :
Here's an updated version of the script. Still slow as molasse though, only perl/C can change that I'm afraid (or another algorithm to check the files). By slow, I mean takes a couple minutes on a XP1800+.
16 bits resources ar not checked for now, would need the trivial addition of -O res16 to wrc args for the output file to be usable to build Wine.
Usage: cd to any dir in Wine build tree (including wine/), and launch. It'll check all subdirs for Makefiles and extract its needed information from that, no need to tell it were to look.
The output is what's missing (or different) for some types of resources (DIALOG, DIALOGEX, MENU, STRINGTABLE, UserResource for now) compared to LANG_ENGLISH. Some other resources types (ACCELERATOR, BITMAP, CURSOR, GROUP_CURSOR, GROUP_ICON, ICON, MESSAGETABLE, RCDATA, VERSIONINFO) are assumed shared for all languages, so they are skipped. Other resources types are absent from the Wine tree, so no decisions have been taken for now one way or the other.
A nice summary is not included for now, but should be pretty easy to add (and is planned for the short term). Also planned is something along the lines of the "last update" token idea from Dimi.
Vincent