First, a short explanation of the use case: 1. User runs poedit (aka potooledit) on a partially translated po file. 2. Poedit retrieves only the untranslated messages from the file (by filtering it through potool -fnt) and puts them into a temporary po file 3. Poedit launches $EDITOR on that temporary po file 4. User does some translation, saves the file, exits the editor 5. Poedit merges the original and the temporary file back together Now, to reproduce the bug: 1. use an editor which can auto-detect the file encoding, e.g. vim AND 2. run poedit on a file which is in encoding A, while your locale is set to use encoding B. (where neither A nor B is a subset of the other. For example UTF-8 and Latin2) What happens in step 3 is that vim looks at an ascii-only file (since msgids are in POSIX locale) and when the user inputs the translation in her own language, the editor decides to use encoding B (since it's the locale default). Then in step 5 poedit merges the original (in encoding A) and the temporary (in encoding B) creating a broken and a difficult to fix file with different parts in differing encodings. Does anyone have any ideas on how to fix this properly, keeping in mind that poedit is editor-agnostic so it is hard to determine what encoding the editor has chosen to use for the temporary file. The only metadata available seems to be the Content-type field of the header in the original po file, but I can't see how to enforce it for the temporary file... -- Marcin Owsiany <porridge@debian.org> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Attachment:
signature.asc
Description: Digital signature