[Lazarus] Translations / Localizations for controls at design time
avishai.gore at gmail.com
Tue Jul 31 19:28:40 CEST 2012
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 <
juergen.hestermann at gmx.de> 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
> >> 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
> Lazarus at lists.lazarus.**freepascal.org<Lazarus at lists.lazarus.freepascal.org>
avishai.gore at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lazarus