I'm updating the spanish translation of biblio module from 1.9 to 1.10
The steps I did was:
1.- Install drupal + biblio 1.10 + potx
2.- Import de 1.9 biblio translation
3.- Go to http://localhost/drupal/?q=admin/settings/locale/string/search and search the "Non translated Strings"
4.- Edit the strings.
5.- Go to http://localhost/drupal/?q=admin/settings/locale/potx and extract the spanish template for Biblio
Some strings was missed. In my drupal local server are translated, but not in the .po file. I don't know if is relevant, but all the missing strings I revised (not all yet) have an spanish "special" character (ñ, é, í, etc...). Some other strings with this characters are extracted ok.
Screenshot and .po file attached
Comment | File | Size | Author |
---|---|---|---|
#7 | potx.inc_.zip | 11.09 KB | Gocho |
bug_example.png | 255.36 KB | Gocho | |
biblio.es-buggy.po_.zip | 8.44 KB | Gocho |
Comments
Comment #1
Gocho CreditAttribution: Gocho commentedA second revision shows me why the strings was not extracted. All the missing strings have the " character in it.
It's seems as potx doesn't converts the " character to \" when extracts the strings.
Comment #2
Gábor HojtsyHm? The attached shot shows the "By default..." string on the interface and extracted as well. Now what is missing? It would be better to know more about what was missing. Also, did potx provide an error message about those? (After you reload the export page).
Comment #3
Gocho CreditAttribution: Gocho commentedThe problem is that potx doesn't extract the translated strings when they have any " character.
As you can see, the "By default..." was extracted, but the translated one doesn't.
For the original string potx extract it ok and converts the " characters to \" but doesn't for the translated.
Comment #4
Gábor HojtsyAh, i see. The problem is that when _potx_translation_export() gets called, it gets called with the escaped source string, so it will not find the translation in the database. The reverse of _potx_format_quoted_string() should be applied when calling _potx_translation_export(). From the looks of how _locale_import_parse_quoted() does it, we might be enough with calling stripcslashes($string) on the value passed to _potx_translation_export(), whenever it is called. Can you test this?
Comment #5
Gocho CreditAttribution: Gocho commentedNo luck :(
I edit the potx.inc callin stripcslashes() before _potx_translation_export() and the bug is still here.
The only place where I edit in the potx.inc file is the _potx_build_files function:
Comment #6
Gábor HojtsyThe stripcslashes($singular); does not modify $singular, but $singular = stripcslashes($singular); does :) The same for $plural should be done there and the same for $string.
Comment #7
Gocho CreditAttribution: Gocho commented:$
Great! Now works ok. Thanks :)
New version of potx.inc attached and ready to be comitted.
Comment #8
Farreres CreditAttribution: Farreres commentedWhen will this be committed? I think it is a rather important bugfix to generate a new official version.
Comment #9
Gábor HojtsyFully agreed. I still need to work out how this will get into the four branches of potx: 5.x-1, 5.x-2, 6.x-1, 6.x-2
Comment #10
Gábor HojtsyHm, finally found some time. Committed the fix to all four branches, and released the 5.x-1.1 and 6.x-1.1 versions. The 6.x-2 and 5.x-2 versions are still in development but their latest snapshots will have the fixes.
Note that I have finally implemented a different solution, as it can be seen in the diffs, I modified _potx_translation_export(). http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/potx/potx.i... I hope you find this working just as well, as it is just the same code moved to a little bit different place (maybe more logical, but I am not 100% sure). Thanks for testing!
Comment #11
(not verified) CreditAttribution: commentedAutomatically closed -- issue fixed for two weeks with no activity.