How do all the metapost parts fit together.
wookey at aleph1.co.uk
Tue Sep 9 12:53:35 CEST 2003
+++ Stacho Mudrak [03-09-08 16:04 +0200]:
> On Mon, 08 Sep 2003 22:11:24 +1000, Michael Lake <mikel at speleonics.com.au>
> If somebody would
> like to check our point, line and area types and write comments about it
> What has a wrong spelling?
> What is not understandable?
> What names should be preferred? (for example: we use popcorn (US) not
> cauliflower-calcite (UIS))?
> What symbols are missing?
I'll try and look these over whilst packaging the next version. Although
I'll be very happy if Mike beats me to it :-)
> OK, some words about our view of internationalization:
> Therion input files language will be only english (like survex). In fact,
> it's a code and I have a very negative experience with code written in
> other languages (Micro$oft once released VisualBasic in SLOVAK (something
> really nasty) - in the next release, they came back to english)
> 2. We're also not keen on putting other languages into xtherion. The reason
> is simple, I've a very bad experience with all programs translated into
> The translations are usually less understandable - a lot of technical terms
> have their equivalents in Slovak - but in Slovakia usually english terms
> not Slovak are used (ok, may be in France or Germany it's different :). And
> also, there are allways problems with regional special characters...
> The last thing is - that terms like stalactites, helictites etc. are a part
> of input files - so people should understand them anyway. Like they
> understand words like length, bearing, clino in survex.
I understand what you are saying - I agree that anything in xtherion which
is really referring to the element names in the therion input file should
match up. On the other hand it is definately necessary to have proper local
language translations for menus, error messages, help and documentation to
allow software to be widely used by those who don't already speak good
Eventually the xtherion interface should get to the point where many users
will only use it via the graphical interface and won't be editing text files
much at all. When that is true it is important that the meaning of symbols
is easily understood, and the cross-reference to the code in the data files
becomes less significant.
So, I do think that translations are necessary in the user interface, but
I agree that the need for the correspondence with the data-files to be
clear, makes this problem harder than usual. Displaying both a translation
and the string that will be netered in the data-file is probably best, but
it might have to be switchable because they won't both fit on the screen.
We probably have more important things to worry about at this stage, but I
don't think it's right to say 'xtherion is only in english' as a policy.
Survex's portuguese support, for example, has made it very popular in
Brazil. This wouldn't have happened if it had been english-only. And survex
has the same aspect as therion in that the data files are essentially in
english. Translating the user-interface is definately a good thing and we
should put the infrastructure in place, otherwise whilst the output can be
read by anyone, only those who read good english can use the software.
> 3. Therion map and atlas output will be translated into other languages
> probably very soon. When it will generate lists of map symbols, they will
> be described in local language.
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
More information about the Therion