[plt-translators] english-string-constants.ss update

From: Philippe Meunier (meunier at ccs.neu.edu)
Date: Mon Aug 4 06:02:08 EDT 2008

Eli Barzilay wrote:
>I hope that you're also reading the commit messages -- for example,
>for the two strings that I plan to remove very soon I'd write in the
>log message that I removed them from all files.

No, I don't, because I can't rely on developers to not forget to
always write such things in the log message or to write meaningful log
messages at all, even if I were to add a new rule about that, so I'd
have to check and do what I do right now anyway when a string is
deleted from english-string-constants.ss: do an 'svn update' followed
by a grep in the other files.  I'd also have to play the log message
police when developers do not follow such new rules about log messages
(on top of already playing the 'developers should not rely on
translators to do their work for changes which do not require
translations' police) and, while I love to kick asses, I don't really
feel like starting to bitch at people because of their svn log
messages :-)

>> Ideally you'd want to have a GUI that all developers use to modify
>> english-string-constants.ss, which would then automatically
>> propagate all the changes to the other files when possible
>> (deletions, renamings) and otherwise keep track of all the
>> translations that remain to be done for each file and would tell
>> each translator about it on request...
>That kind of GUI doesn't sound like a practical thing, because some
>edits can be done by developers -- like removing parens, or renaming
>PLT to TLP.

Nothing prevents a developer from temporarily playing the translator.
In fact Robby did just that when he removed all the stuff between
parentheses in the various translations of some string.  There is no
clear line between developer and translator, the goal is just for
developers to do as much as they can and let the translators do the

>But what does some very good is an interface for
>translators -- something that will (for each lanagueg) nag you about
>strings in english that are not in your language; warn you about
>strings in your language that are not in english;

Drscheme already does this every time you start it with the
PLTSTRINGCONSTANTS environment variable set.

To be honest, I'm not interested in a tool that's going to nag me
about doing something.  I update the french version in batch mode
every 3-4 months when I have nothing else more urgent to do, and I
have an amazing capacity to ignore nagging (ask Matthias :-))

I'm much more interested in a tool that helps developers do some basic
tasks (deleting, renaming) in parallel on all the files and does
enough bookkeeping so that translators (or developers playing
translators, for simple cases) can easily know what remains to be done
manually (and even why: translating a new string is different from
changing the translation of an existing string, etc.)

>and will keep track
>of changes so if there was a change in an english string but no change
>in your string, then it'll be highlighted as "requires attention".

Yes, this would be nice to have.  Currently in such a situation The
Rules say that people are supposed to comment out the old string in
all the files and to add a comment telling translators that the string
has changed (the old string is only commented out, not deleted, in
case it is useful as a starting point for the new translation...)  The
problem with that is that nothing prevents a translator from missing
the commented out version when reading his file, so in practice it
only really worked if the developer sent an email to let translators
know that he commented out the string and why.  In short, the current
rule to solve this problem is half-baked, but that's the best I could
come up with when I wrote the rules.  Nowadays the posted diffs pretty
much solve this problem, since they make it more obvious when a string
is changed in english-string-constants.ss so the commenting-out is not
really necessary anymore, though the rules have not been updated to
reflect that, and the problem is still there if a translator
accidentally deletes an emailed diff before doing the corresponding

>I imagine something like this with a web interface, which will boil
>down to getting an email every once in a while, and doing most of the
>work in the browser.

I'd rather have a drscheme tool that works on a local copy of the svn
tree.  For one thing, my internet connection sucks, and for another
thing it would allow me to double check the result before doing a


Posted on the translators mailing list.