[Lazarus] Translations / Localizations for controls at design time

[Avishai]

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
> 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
> Lazarus at lists.lazarus.**freepascal.org<Lazarus at lists.lazarus.freepascal.org>
> http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarus<http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus>
>



-- 
Shalom,
Avishai
avishai.gore at gmail.com
אבישי גוֹר
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20120731/5cfd5c6d/attachment-0003.html>