[Lazarus] Pochecker (was Fuzzy traslations ignored)
Giuliano Colla
giuliano.colla at fastwebnet.it
Fri Oct 10 13:40:47 CEST 2014
Il 10/10/2014 11:01, Mattias Gaertner ha scritto:
> On Fri, 10 Oct 2014 10:04:26 +0200
> Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:
>
>> [...]
>> Editing tools accept a .pot file as a starting point to generate the
>> first copy of your localized versions (for a new translation).
> A valid point.
> Although I'm not sure why the generated header matters here.
It contains information which currently is irrelevant for Translations
unit, but which can be useful to editing programs, or just to a new
translator picking up a previous translation.
From a quick browsing, it would appear that Translations unit currently
doesn't supports multiple plural forms existing in some languages (e.g.
singular, dual, and plural form, for n=1, n=2, n= 0 or n>2 respectively.
See:
http://localization-guide.readthedocs.org/en/latest/l10n/pluralforms.html ),
but should it do it one day, the information of how many plural forms
are used in that language, and the rule for picking up the righe one is
one of the things found on the header generated by translation tools.
But, as far as translators are concerned, the main point is that the
process is much easier for a not-too-much IT literated translator. He
doesn't need to locate a template file, which at first glance is
identical to other translation files, and copy it renamed to his/her
locale. With .pot extension, most translation tools take care of that
automatically, given the translator language (header info again)
> An important point are the new units with dots in their name.
I agree with you. It's difficult to be sure that the heuristics based on
filename structure, currently used to detect a template file, won't fail
with filenames more complex than a basic unitname.po / unitname.lang.po
> The IDE could check if unitname.po exists.
> If it does: update that for compatibility.
> If it it does not: update/generate a pot file.
> Would that help?
I'd be in favor of a smooth transition versus .pot only templates.
IDE could search for unitname.pot first. If not found search for
unitname.po, and, if found, rename it to unitname.pot, thus deleting
unitname.po (I don't see any reason to keep it). Then proceed as usual.
I'd say that only a small portion of TMainIde.UpdateProjectPoFile in
main.pp is involved, but you know better than me.
After a grace period, support for unitname.po templates could be dropped
completely (Lazarus 2.0 or maybe Lazarus 3.0)
This would be completely transparent to translation maintainers, which
deal only with their .po files, and would involve a minor adjustment to
PoChecker.
>> I wouldn't give a damn on what gettext says either, if it weren't that
>> by not following its rule we generate troubles:
>>
>> 1) we have template files and translation files (which are two different
>> beasts) with the same extension, and programs must figure out, by other
>> means, which one is which.
>> It's much easier and cleaner to tell them apart by a different extension.
>> Moreover, sometimes the figuring out fails, as in the case of the files
>> on the debian/po directory, where translation files are mistaken for
>> templates.
> In this case the template is called 'templates.pot' and the
> translations '??.po' instead of 'templates.??.po'. So this seems
> to be a special case.
> And note that these strings are not from a Pascal unit and are not
> used in an LCL application.
They've only been an incident, showing that an heuristic approach, based
on file name structure, is less reliable than a dedicated extension.
They could be treated as a special case, when looking for templates and
translation files in the Lazarus tree, but as there's a cleaner and more
general solution, why not take the occasion of this incident to adopt it?
Giuliano
--
Giuliano Colla
Project planning question: when it's 90% done, are we halfway or not yet?
More information about the Lazarus
mailing list