Am Wednesday 15 August 2012 13:39:11 schrieb Marco van de Voort: > In our previous episode, Rainer Stratmann said: > > > You already have a very good grasp of the issues involved as you were > > > writing your own solution. You could probably improve dxgettext with > > > some things and get that in the main development tree, thereby > > > improving things for others. > > > > As I read now here > > http://dxgettext.po.dk/ > > gettext seems already to be a (very) good solution. I am wondering why > > there are some problems with as I read somewhere in this thread. > > Limitations, not problems. Compared to the Delphi internal translation > systems. Yours has the same, by design.
Which limitations? > Note that I think dxgettext is a netto plus compared to ITE. I do not understand what you mean here. > If your source (main) language has a word with two meanings, how will you > translate to a language where there is a word for each meaning? You mean 2 words spread over the program? Then I can put an additional identifier like already mentioned. ls( '~ID1~word' ); ls( '~ID2~word' ); In this case ID1 or ID2 is the identifier instead of 'word'. But in all cases 'word' is the result of the translation of the original language. > IIRC dxgettext has only solutions for that when you recognize this early > and add special code. This means that sometimes you can't simply ship a > translation, but also have to In my case it can also be possible that there are not all words translated yet. Then the original text is shown or englich one. The translation can be made later. That is (also) an advantage. > (dx)gettext also has support for stuff like multiples, textdomains. Some of > it is not very well supported in the editor (gorm) though. I will use a browser as editor. So the utf8 (and unicode?) converting is made automatically by the browser. I have some code for converting ascii <-> utf8. > > For me it would be interesting to know how dxgettext gets the snippet > > information from the program code...! > > It comes with source scanner tools to harvest strings from the code. Another step more that means more work and less easiness (less userfriendly). > The source for this + the editor are available. Most will readily work with > FPC/Lazarus, except maybe unicode issues. > > What's your unicode philosophy btw? I need a converter from ascii to unicode. Then the browser can show this I think. With uft8 it works already. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
