AutoTranslate based on user Loacle is a disastrous idea, especially if the program is multi-lingual. Eventually what should be LangA - LangB will end up on a system where it is LangA - LangA and make no sense at all. AutoTranslate also fails badly on such things as LongMonthNames[N] if the Locale is RightToLeft. It returns '???'. The workaround is easy, but I spend too much time writing workarounds. And unless you test with both LeftToRight Locale and a RightToLeft Locale, you are likely to assume that AutoTranslate will take care of you. You will likely be wrong.
On Tue, Jul 31, 2012 at 7:39 PM, Jürgen Hestermann < [email protected]> wrote: > Am 2012-07-31 18:15, schrieb Graeme Geldenhuys: > > > In my opinion, your way is a terrible way to do localization! For > > reasons as follows: > > * No auto-detect of language when the application starts up. > Why is that not possible? If you can detect the language then you can also > simply set the language variable to whatevery is needed and call the > caption-routine that switches all captions to the selected language. > > > > > * When new languages are added, you must rebuild the whole application > > (executable). > Yes. But why is this a drawback? It speeds up application start because > all is in one exe file without having the need to load a separate language > file on startup. > > > > > * You can't use any of the existing PO translating tools which have > > some brilliant > > features like built-in dictionaries, suggested translations, spell > > checking etc. > Well, I mostly find all these "brilliant" features more disturbing than > helpful. And you also have a learning curve to investigate in these tools > that eats up time. > > > > > * Quickly see a percentage of translation per language. > What do you mean? The number of languages that have been translated? Ok, > this might be an issue in a very huge project with hundreds of developers. > > > > >> Sometimes > >> translations are very crude because someone simply translates the text > one > >> by one like a google translator without knowing what it means and the > >> outcome is often misleading. > > That is why it is important to use good & clear resource string > > constant names. The constant name alone (and maybe with the help of > > existing translations) should make it clear in what context it is > > used, thus helping the translator. > > rsDate = 'Some Date'; > > rsTitle = 'Some dialog title'; > > vs > > rsAccountingTransactionDate = 'Some Date'; > > rsCentreMaintenanceDialogTitle = 'Some dialog title'; > > Well, this reduces the probability of miss-translation but if you have the > code nearby and maybe even comments then you have much more information of > what is meant in this case. > > Also, sometimes the length of the text is important too (so that a button > caption can still be displayed and does not exceed the borders). If you > only see a variable name then you don't know about these constraints. > > > > Nevertheless, if lots of people are working on a large project an external > file may be of use because the translator may neither be a programmer nor a > program user (although in such cases translations are not very good IMO). > But for smaller projects this is very convenient and saves cluttering > information in too many files and has the mentioned advantages. > > > > -- > ______________________________**_________________ > Lazarus mailing list > [email protected].**freepascal.org<[email protected]> > http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarus<http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus> > -- Shalom, Avishai [email protected] אבישי גוֹר
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
