OpenConnect translations

Jussi Kukkonen jku at linux.intel.com
Tue Sep 27 10:17:42 EDT 2011


On 09/27/2011 02:13 PM, David Woodhouse wrote:
> I've finally added NLS support to OpenConnect, so it should be able to
> output its messages in your native language rather than only in English.
> 
> This obviously depends on actually *having* translations of its
> messages, though.
> 
> Any contributions of translations, even if you only have time to do a
> few messages rather than a full set, would be much appreciated.
> 
> You can either do this in Transifex:
> 	https://www.transifex.net/projects/p/openconnect/
> 
> or just by sending me patches to the relevant po/$LANG.po file with some
> translations filled in. Or even just send me the edited file if you
> can't work out how to do patches; all contributions will be gratefully
> received. 
> 
> I've fixed a couple of places where the way that messages were
> constructed were likely to cause problems for sane translation, such as
> where it had one "reason" string which was set to either "has expired"
> or "expires soon", and it then printed a message
> 	"Client certificate %s at:"
> including the reason. I've turned that into two separate strings which
> can be independently translated. If there are *more* places where I
> should change the original in order to make the translations
> better/easier, please let me know.

This needs changing as well:
msgid "Discard bad split %sclude: \"%s\"\n"

Also,there are some strings in tun.c that look like they maybe shouldn't
be translated (or really need a translator comment):
msgid "statvfs: %s\n"
msgid "statfs: %s\n"
msgid "SIOCGIFFLAGS"
msgid "SIOCSIFFLAGS"
msgid "SIOCSIFADDR"
msgid "SIOCSIFMTU"
msgid "socketpair"
msgid "fork"
msgid "execl"
msgid "(script)"
msgid "TUNSIFHEAD"
msgid "ioctl(I_PUNLINK)"


I'm guessing there are places where translators need more context to
actually make high quality translations. It's difficult to say where
comments are needed as a developer -- which is why I tend to add
comments for every string that isn't blindingly obvious. GUIs are more
complex in that regard so that's probably not needed here but adding a
few comments would definitely help:
 * Context of the string when it's not obvious, e.g. that string "no"
will be used in input comparison and that it should match the text in an
earlier message string
 * Placeholder values: what will be inserted into the strings (if it
isn't obvious), e.g. in "Connected %s as %s%s%s, using %s\n" -- an
example is often enough


To anyone translating: please let David know which strings are difficult
to translate, it can be hard for developers to recognise those but
adding a comment is easy when told to.

 - Jussi



More information about the openconnect-devel mailing list