Could you give me a list of strings to translate user interface? I started editing files in xtherion directory just for fun; after the first rush, I can see aprox 60% of my user interface in spanish. However, I'm getting some nasty errors about bad index entries because I feared to touch some things not marked label or text. I'm not a coder and this is the first time I see Tcl code. Fixed the first four or five errors, but detected others, and got a beautiful freeze just now. Expended more time debugging than translating. Regards, Roman
Could you give me a list of strings to translate user interface?
I started editing files in xtherion directory just for fun; after the first rush, I can see aprox 60% of my user interface in spanish. However, I'm getting some nasty errors about bad index entries because I feared to touch some things not marked label or text. I'm not a coder and this is the first time I see Tcl code. Fixed the first four or five errors, but detected others, and got a beautiful freeze just now. Expended more time debugging than translating.
I'm afraid that xtherion is not really prepared for translations :-( Few months ago there was a discussion about translating it; I append the substantial parts. M. ---------- Forwarded message ---------- From: "Martin Budaj" <m.b@speleo.sk> To: therion@speleo.sk Date: Mon, 14 Jun 2004 13:12:49 +0200 (CEST) Subject: Re: [therion] new user ....
- Is there any plan, or any contact taken, for a french translation? If not, and if you think that internationalisation could be easy enough in the current version of the code, I could find the time to help you for that...
Well, there were more requests to translate therion to other languages. This can be done on more levels (which one do you mean?): - map output - console messages from therion - xtherion's user interface - input language (commands) - documentation The first is fully supported and we have already Czech and Slovak translations. Contributions are welcome. The last requires more effort while the documentation is changing and growing rapidly. IMHO all other three fields (messages, UI, input language) are deeply wedded together -- I see no great advance in translating messages if xtherion's interface remains English, and only confusion if the UI gets translated but the user has to fill english options for commands (E.g. you see translated label 'options' in your language but have to fill '-subtype ...' in English) On the other side, translation of the input language could create a total mess. What about Punkt 0 0 Wurzel -Sichtbarkeit ein -abschneiden aus or bod 0 0 kore? -vidite?nos? áno -oreza? nie The only real solution I see is to make the GUI in such a way that therion and its language would be completely hidden. see http://labyrinth.speleo.sk ---------- Forwarded message ---------- From: Eric Madelaine <madelain@nerim.fr> To: therion@speleo.sk Date: Mon, 14 Jun 2004 23:05:31 +0200 Subject: Re: [therion] new user ....
Translations - map output The first is fully supported and we have already Czech and Slovak translations. Contributions are welcome.
Ok, this one is easy, I volunteer gladly for a french translatin.
- documentation The last requires more effort while the documentation is changing and growing rapidly.
Well, yes... Ok, I will not promissed any large amount of work just now. But I'll think about what I can do, and I will certainly do some introduction paper in french, in the same spirit than wookey's paper in Compass Point.
- console messages from therion - xtherion's user interface - input language (commands)
Console messages and UI are going together (just as they go in survex and the survex-related tools, for which I do contribute my own set of french sentences from time to time...). But this is why I wrote "if the code already supports internationalisation...". So I undertsand that it is not yet the case, and I will not push it anymore (:-( Input language is a separate topic, I agree. But then, I'm not sure why you would not be able to change the lexer without changing the rest of the parser, and get variants for the language... (Again, I'm not suggesting that you should do it) ---------- Forwarded message ---------- From: Stacho Mudrak <s.m@speleo.sk> To: therion@speleo.sk Date: Tue, 15 Jun 2004 10:08:21 +0200 Subject: Re: new user ....
Ok, this one is easy, I volunteer gladly for a french translatin.
OK, I'll have a look at the code and then I'll write you what exactly to do (I do not remember now :) .
- documentation The last requires more effort while the documentation is changing and growing rapidly.
Well, yes... Ok, I will not promissed any large amount of work just now. But I'll think about what I can do, and I will certainly do some introduction paper in french, in the same spirit than wookey's paper in Compass Point.
I'm afraid, there is no comprehensive documentation to translate. ThBook is just a reference guide - I think, it will not help people, even if it will be translated.
Console messages and UI are going together (just as they go in survex and the survex-related tools, for which I do contribute my own set of french sentences from time to time...). But this is why I wrote "if the code already supports internationalisation...". So I undertsand that it is not yet the case, and I will not push it anymore (:-(
Not exactly :) The internationalization code works in therion. Adding translation for 50 messages that therion generates is a work for 30 minutes. Also translating things in xtherion wouldn't be much work (I guess one evening) within the same framework.
Input language is a separate topic, I agree. But then, I'm not sure why you would not be able to change the lexer without changing the rest of the parser, and get variants for the language... (Again, I'm not suggesting that you should do it)
This is again very easy - to add alternatives to parsing tables. In fact, they are already there to cover UK/US variants :))) pit/pitch, center/centre etc... We are just afraid of a mess, that can happen... I'm almost sure, that if I would write bod 0 0 -typ bre`ko nobody in the world with exception of CK/CZ would understand this code... In any case, internationalization is a topic for discussion. Last week we have realized, that at least, we should allow also real numbers with comma (e.g. 3,5), because otherwise people must allways switch to english keyboard. ---------- Forwarded message ---------- From: Olly Betts <olly@survex.com> To: therion@speleo.sk Date: Tue, 15 Jun 2004 16:22:15 +0100 Subject: Re: [therion] new user .... On Mon, Jun 14, 2004 at 11:05:31PM +0200, Eric Madelaine wrote:
Input language is a separate topic, I agree. But then, I'm not sure why you would not be able to change the lexer without changing the rest of the parser, and get variants for the language... (Again, I'm not suggesting that you should do it)
It's possible, but it's not a sane route to go down. The problem comes when users using different i18ns want to exchange files (for example, CUCC shares survey data with the German cavers who work in the same area of Austria). Worse, what if I want to change a survey data file sent to me in German? I'm forced to try to understand the German version of the file format, and either I have to make my changes in German, or the parser will need to understand every keyword from every language at once! A real world example - Microsoft translated keywords in the macro language for either Word or Excel (maybe both!) so a coworker had a fun time translating some macro scripts we shipped to clients by installing both versions and comparing the two manuals...) And of course each time the macros changed, he had to dig out the manuals, and retest everything on the translated version. A better approach would be to translate the keywords from english (or some canonical form) and back to the canonical form on save. That way I can edit a data file from a German surveyor in English, and the language used in the file format becomes just an implementation detail,
Martin, I understand how translating is a complex work. However, we are considering to organize some survey stages and need good software for it. I think therion is a serious candidate for many reasons. But we need it (mostly) translated because: First: obviously all the people needs get map output in their own languages, I think texts_xx.txt files are just for that. Right? Next, to have an untranslated user interface is one of the most scary things to my friends. If translated, they can play quite easy, and, being therion as good as really is, there is a probability for it to be adopted. But, with untranslated user interface, no chance. Friends will remain with Visual Topo, which is not bad software, and is translated. Third, thbook is very good as reference book, but it is not a starter guide IMHO. There was perhaps a year ago I see therion for the first time, getting a quite pretty headhache and running away with the tail between the legs. No offense intended. This time, I got it, but I'm really missing a starter guide so I could play with my first cave quickly. Input commands: Yes this is a problem. Friends are used to put their data, not to output commands. Language does not matter. Hopefully, to get a centreline for a "normal" cave seems not to need a lot of commands, so I was considering seriously to do some scripting work in order to get spreadsheet data converted to .th files, at least for easy caves. That mentioned (some days ago) import module would be great. But I could always do the stage with only some few commands and .th template files to explain how it works. Not so difficult. Console messages: If all the rest works smoothly, I don't care so much about them. May be am I making a mistake? So, if output map is in spanish thanks to texts_es.txt, next step is to get user interface translated too. I have map editor window fully translated and working now. I made a string list where file, line number and old/new strings are listed. I tested map editor and it seems to work OK. String list is not tested yet. I hope user interface will be fully translated next week. Newer versions of therion will probably change and may be this translation will become useless for them, I understand it. But at very least we will have one translated version to get people introduced to therion. BTW, it *must* to work in windows, this is the nastiest thing... After this, I'll be ready to start writing that starter guide, expect to get quite a lot of questions about therion tips, etc ;-) Only after this I could think about translating thbook reference Cheers, Roman
+++ Roman Muñoz [05-01-23 18:52 +0100]:
Next, to have an untranslated user interface is one of the most scary things to my friends. If translated, they can play quite easy, and, being therion as good as really is, there is a probability for it to be adopted. But, with untranslated user interface, no chance. Friends will remain with Visual Topo, which is not bad software, and is translated.
You are quite right that everyone deserves an interface in theri native language, but therion is a trickier case than most software. Because the interface is really just an aid to editing the data files, thier format is exposed a great deal in the interface. I don't think it is practical or sensible for therion to have a different file format for every language, so some english will show through in the UI until someone writes a UI that hides the data format completely, and we are a long way from that now. However I'm sure a significant amount of UI translation is possible, whilst keeping the syntax the same. I assume that is what you are trying to do. It will make things a little more confusing by adding yet another layer of indirection (from the test in the UI to text in the file, which will only match up when the UI is english), but most of the time this will not be too much of a problem.
Third, thbook is very good as reference book, but it is not a starter guide IMHO. There was perhaps a year ago I see therion for the first time, getting a quite pretty headhache and running away with the tail between the legs. No offense intended. This time, I got it, but I'm really missing a starter guide so I could play with my first cave quickly.
I wrote one a year or so ago for therion 0.2.19. It is now a bit out of date, but I think it is the most useful existing starter guide. You can read it here: http://www.chaos.org.uk/~wookey/CP33.pdf Martin is working on including it in the thbook and.or website I think. I could write an 'intermediate' one now :-)
After this, I'll be ready to start writing that starter guide, expect to get quite a lot of questions about therion tips, etc ;-) Only after this I could think about translating thbook reference
Feel free to translate my article - it is GPL-licenced. 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/
Wookey wrote:
You can read it here: http://www.chaos.org.uk/~wookey/CP33.pdf
Martin is working on including it in the thbook and.or website I think.
There were some pictures missing. I'll link your pdf directly from the web page.
I could write an 'intermediate' one now :-)
That would be really helpful ;-) Martin
Roman Muñoz wrote:
First: obviously all the people needs get map output in their own languages, I think texts_xx.txt files are just for that. Right?
Yes, I will put it into 0.3.6.
Next, to have an untranslated user interface is one of the most scary things to my friends. If translated, they can play quite easy, and, being therion as good as really is, there is a probability for it to be adopted. But, with untranslated user interface, no chance. Friends will remain with Visual Topo, which is not bad software, and is translated.
OK, putting all strings from xtherion to separate files should be a question of one evening. May be I should google for some tcl i18n package and it will be even easier. I will have a look, but it will not be in the next release.
caves. That mentioned (some days ago) import module would be great. But I could always do the stage with only some few commands and .th template files to explain how it works. Not so difficult.
I will have a look at VTOPO once more. It looks to me, that importing it should not be a huge problem. Than, they will be enabled to use VTOPO for centerline processing and therion only for drawing of maps.
Console messages: If all the rest works smoothly, I don't care so much about them. May be am I making a mistake?
Again, if people are interested, putting all strings into translation macro is a question of hour or so. In therion, i18n is already working. Regards, S.
At 23:09 +0000 23.1.2005, Wookey wrote: *******************************************
I wrote one a year or so ago for therion 0.2.19. It is now a bit out of date, but I think it is the most useful existing starter guide.
You can read it here: http://www.chaos.org.uk/~wookey/CP33.pdf
Wookey, may you add your starter guide to wiki pages? TIA BR MS. --
s.m@speleo.sk said:
Again, if people are interested, putting all strings into translation macro is a question of hour or so. In therion, i18n is already working.
Well, I've not be very active here since the first french translation (for produced maps), but I guess that I could use this opportunity to come back (;-) s.m@speleo.sk said:
I will have a look at VTOPO once more. It looks to me, that importing it should not be a huge problem. Than, they will be enabled to use VTOPO for centerline processing and therion only for drawing of maps.
Yes Stacho, this can be a first useful approach. Of course there are many users of Vtopo in france (and more generaly in french) so this could be a large user community. A (not very optimised, but nevertheless useful scenario) scenario could be: - use your Vtopo data to print a centerline + LRUD information, draw and scan the onscale hand drawings (plan and extended elevation) - automaticaly get the therion centerline data - draw the scratches with therion map editor, and use some naming schemas to relate them. The fisrt limit to this approach is that Vtopo has no naming structure, so usually people get huge vtopo files with all surveyx of a given cave inside. At best they use the "merge" feature, when dealing with several caves in a given area (but the merge is based on entrance coordinates, and I've not found a way to twist this feature to deal with surveyx within a given cave, with potential joins inside). So you'll get a single big .th file, possibly with several survey sequence within (with diffrenet instruments settings and declination). No theoritcal problem there, just difficulties whne managing big dat sets. Eric.
Eric Madelaine wrote:
Yes Stacho, this can be a first useful approach. Of course there are many users of Vtopo in france (and more generaly in french) so this could be a large user community.
I have played a little bit with VTopo with following results: 1. VTopo has PLT export :) => even existing developement version is able to to import centerline data in this format. 2. Parsing VTOPO .tro files should not be difficult also - but not in next version. In principle, both approaches are almost equivalent. User will have all stations imported to one survey.
A (not very optimised, but nevertheless useful scenario) scenario could be: - use your Vtopo data to print a centerline + LRUD information, draw and scan the onscale hand drawings (plan and extended elevation)
Very soon, we will add support for passage dimensions to be drawn automatically on the background (as a background image). This should enable user to draw maps directly on the screen without printing>hand-drawing>scanning.
The fisrt limit to this approach is that Vtopo has no naming structure, so usually people get huge vtopo files with all surveyx of a given cave inside.
At best they use the "merge" feature, when dealing with several caves in a given area (but the merge is based on entrance coordinates, and I've not found a way to twist this feature to deal with surveyx within a given cave, with potential joins inside).
So you'll get a single big .th file, possibly with several survey sequence within (with diffrenet instruments settings and declination). No theoritcal problem there, just difficulties whne managing big dat sets.
Well, if they do not wish to convert centerline data (they will keep them in original format and therion will be able to import VTopo .tro files), huge files are not necessary. In therion, you can input files without any survey command. And maps have also tree structure independent of surveys. Therefore you can have each piece of map in separate .th2 file and maps structure can be also divided into several .th files. If they would like to convert centerline data to therion -> it would be better for them to create survey structure from the beginning. But I think, that new user will be afraid of converting his dataset to "unknown" and "complicated" software. Especially, if there will be import command and maps can be drawn directly without this conversion. Regards, S.
On Mon, 24 Jan 2005 14:36:08 +0100 Stacho Mudrak <s.m@speleo.sk> wrote:
1. VTopo has PLT export :) => even existing developement version is able to to import centerline data in this format.
(...)
Very soon, we will add support for passage dimensions to be drawn automatically on the background (as a background image). This should enable user to draw maps directly on the screen without printing>hand-drawing>scanning.
Very good news! BTW, I finished translation of user interface. I have a pipe-separated list of strings, with these fields: file|line number|original string|translated string| I can send to you if you think it could be useful. Best regards, Roman
Roman Muñoz wrote:
BTW, I finished translation of user interface. I have a pipe-separated list of strings, with these fields:
file|line number|original string|translated string|
I can send to you if you think it could be useful.
I will have a look and let you know. In any case, translation will be a hash of translated strings with original string as key. So it will be probably very easy to use your file, when xtherion will be translated. But now we would like to finish 0.3.6 and release it. Then we can start working on these new things. Regards, S.
participants (6)
-
Eric Madelaine -
Martin Budaj -
Martin Sluka -
Roman Muñoz -
Stacho Mudrak -
Wookey