Red Hat Bugzilla – Bug 1026763
Locale::Maketext interpolating escaped backslashes improperly
Last modified: 2014-07-02 09:35:17 EDT
+++ This bug was initially created as a clone of Bug #1025906 +++
Description of problem:
When a literal backslash is in an L10N value, it is treated nonuniformly by the Locale::Maketext::_compile method, as patched by RH in Locale::Maketext::Guts (per https://bugzilla.redhat.com/show_bug.cgi?id=884354). The result depends on unrelated parts of the string.
Steps to Reproduce:
1. Create a language token, whose value is 'Some data\n'
2. Query the language token through Locale::Maketext ($lh->maketext($tag))
The behavior changes in the following cases:
1) If the value contains a tokenized field, behavior depends on whether there is a trailing newline:
'[_1]Some data\n' => 'Some data\n'
'[_1]Some data\n'."\n" => 'Some data\\n
2) If the escaped backslash is in a function call, it behaves as expected:
'Some data[sprintf,\n]' => 'Some data\n'
NOTE: All of these cases in standard perl (with Locale::Maketext v 1.13 from CPAN) behave exactly the same as each other, and they all produce just a single '\' before the 'n'.
--- Additional comment from Petr Pisar on 2013-11-04 12:16:19 GMT ---
The 'Some data\n' is due to back-porting the fix to perl 5.10.1.
The parameterized case behaves for me differently and is caused by the changes in the fix. Even latest Locale::Maketext is affected.
All Fedoras are affected.
perl-Locale-Maketext-1.23-293.fc20 has been submitted as an update for Fedora 20.
perl-Locale-Maketext-1.23-293.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.