[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