#1053 closed defect (fixed)
Small changes (typos, semantic differences) to ES translation
Reported by: | Owned by: | hugo | |
---|---|---|---|
Component: | Translations | Version: | |
Severity: | normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I made some small changes to the current ES translation, added a few missing strings and corrected a few typos.
Attachments (4)
Change History (9)
by , 19 years ago
comment:1 by , 19 years ago
Sorry, but the djangojs.po file is mixed charset: part is utf-8, part is iso-8859-1. It must be either one, but not both (the header talks about uf-8). Please upload a fixed djangojs.po. django.po was already marked in the header as iso-8859-1, so I assume it's fully iso-8859-1 - unless you added some utf-8 chars to it (the compiler can only detect wrong utf-8 chars in files marked as utf-8, not the other way around).
Please bump the ticket when you have checked the files and corrected djangojs.po.
comment:2 by , 19 years ago
That should be it. I used iso-8859-1 in order to match the other, larger file.
comment:3 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:4 by , 19 years ago
This is not important but, I guess it would be better if all files (of all other languages too) used utf-8. That is, that all translations uses unicode instead of having different encodings each. I don't know, but I think that maybe having all kinds of encodings might cause problems in the future.
comment:5 by , 19 years ago
nope, it's just not needed to do - and actually editing utf-8 files in a non-utf-8 environment (which is the case with many people in western europe) is a pain, so why force it on them? gettext explicitely handles different encodings in the message files (it translates them internally to unicode strings anyway) so there won't be any future problems.
Django.po