Re: RFC for users of Locale::Maketext::Lexicon

in reply to RFC for users of Locale::Maketext::Lexicon

I haven't used any of these modules either, but based on the evidence you've shown, it seems like the "legacy" behavior of "Locale::Maketext::Extract / xgettext.pl" is sub-optimal (to put it nicely) because it is non-compliant with the other tools that it is supposed to interact with.

So, speaking as an outsider, my vote would be to change the default behavior so as to make it "correct" (compliant with gettext and POEdit), but keep the legacy behavior as an option (in case anyone has actually created code dependent on that format), and be very clear about the change in the docs. (And mention that this "backward compatible" option will be deprecated.)

Among the people who have used Local::Maketext::Extract / xgettext.pl, I wonder how many of them have considered its original output format to be troublesome because of its divergence from the norm? (For that matter, I wonder if this issue was involved in one of the POEdit change-log entries:

Version 1.3.5
-------------
...
- fixed crash when loading some invalid PO files (#1495970)
...
[download]

Comment on Re: RFC for users of Locale::Maketext::Lexicon Download Code

Replies are listed 'Best First'.
Re^2: RFC for users of Locale::Maketext::Lexicon by bart (Canon) on Nov 24, 2008 at 09:30 UTC
I haven't used any of these modules either, but based on the evidence you've shown, it seems like the "legacy" behavior of "Locale::Maketext::Extract / `xgettext.pl`" is sub-optimal (to put it nicely) because it is non-compliant with the other tools that it is supposed to interact with. No, that is way too strong. They are compatible: they both use "#:" to indicate the source (filename, line number), although one uses one line per entry and the other combines them in one line; and they both use "#." for variables. Their relative order is not actually important. (See the included doc Web localization in Perl in the distro) It's just that `diff` sees them as different. In fact, I wouldn't be too surprised if yet another tool would use yet another (compatible) format for the same data! So, making this module and this one tool compatible is likely not going to fix the problem. Not definitely, anyway. It's just a formatting choice. The difference between these formats is actually much smaller than the different output options for `diff` itself (for example: unified diff vs. normal diff), which you can control with command line switches. So I propose to either use an output format option, possibly in this module (you can use explicit control for every option, or a global named setting, or both), or add an external command line tool to convert any of these compatible outputs to a single common "standard" format. In fact, I think the latter is the most universal practical solution. You may add the formatting options to this module, and build this command line tool on that! I would not just change the format to match the "tool du jour". It won't solve anything in the long run. And no tool will barf on the data just because of this tiny format change — except `diff`. :)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: RFC for users of Locale::Maketext::Lexicon
by bart (Canon) on Nov 24, 2008 at 09:30 UTC

I haven't used any of these modules either, but based on the evidence you've shown, it seems like the "legacy" behavior of "Locale::Maketext::Extract / xgettext.pl" is sub-optimal (to put it nicely) because it is non-compliant with the other tools that it is supposed to interact with.

are

Web localization in Perl

It's just that diff sees them as different.

In fact, I wouldn't be too surprised if yet another tool would use yet another (compatible) format for the same data! So, making this module and this one tool compatible is likely not going to fix the problem. Not definitely, anyway.

It's just a formatting choice. The difference between these formats is actually much smaller than the different output options for diff itself (for example: unified diff vs. normal diff), which you can control with command line switches.

So I propose to either use an output format option, possibly in this module (you can use explicit control for every option, or a global named setting, or both), or add an external command line tool to convert any of these compatible outputs to a single common "standard" format. In fact, I think the latter is the most universal practical solution. You may add the formatting options to this module, and build this command line tool on that!

I would not just change the format to match the "tool du jour". It won't solve anything in the long run. And no tool will barf on the data just because of this tiny format change — except diff. :)

[reply]
[d/l]
[select]

In Section Meditations