+++ Stacho Mudrak [03-09-08 16:04 +0200]:

On Mon, 08 Sep 2003 22:11:24 +1000, Michael Lake <mikel@speleonics.com.au> wrote: If somebody would like to check our point, line and area types and write comments about it like:

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? etc.

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)

Agreed.

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 SLOVAK.

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 english. 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.

OK Wookey -- 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/