From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] GNU Make From: Charles Forsyth Date: Wed, 2 Jun 2004 10:39:56 +0100 In-Reply-To: <1086167278.1328.5.camel@pc118> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 9003bf54-eacd-11e9-9e20-41e7f4b1d025 >>but how do you think natural languages should be accommodated? that's a reasonable question. as it happens, the %r messages are typically the least of your worries, and indeed if you've got real end-users (ie, non-programmers) are often best regarded as internal error diagnostics for implementors, and left as-is so that those implementor will recognise them. it's hard enough debugging programs as it is, without the Chinese Whispers effect compounded by language changes within. for user interfaces we've found historically that the use of a hashed map string -> string works well (it's rather more than that, because there can be pre- and post-processing, but that gives the idea), and any or all %r messages that need to escape can go through that. that overall approach worked well on a big commercial system that supported all the major Western European languages, including dialects. it was much easier to manage than the contemporary msgcat scheme (i think that was it). you need extra things to do sorting, and comparison, and more; and perhaps most of all you need good translators. the scheme allowed annotations for strings, so that one could distinguish `the times' from `The Times', the latter not to be translated, or depending on context(!) to be translated to some local equivalent (eg, `USA Today'), although as that last example shows it's often quite a loose translation.