Re: baffling i18n problem after unicode update
On 21-Sep-07, at 7:55 AM, Kenneth Gonsalves wrote: >> which has problems with the special characters? > > all reports use the same font. And all the other reports display that > particular problem character ok. And, just noticed that the same > problem character that refuses Good uses appears in another part of > the *same* report that doesnt display Good. Ok, so it is just that > one line of code that is at fault - I will keep staring at it until I > find whats bad about 'Good' - thanks for helping narrow it down. solved - I found that the difference between this line and the others is that this particular line was wrapped in a str() - I removed that, and it worked. Thanks a lot. -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: baffling i18n problem after unicode update
On 20-Sep-07, at 7:09 PM, Nis Jørgensen wrote: >> it does - but so do other words that are getting translated >> successfully, and 'Good' itself is getting rendered properly in other >> parts of the site and in other reports >> > Still, those other parts/reports may be doing something slightly > different. I assume that the translations of "Average" and "Poor" are > ascii. Try changing the translation of "Good" to something without > special characters, and see if that helps. If it does, you at least > know > that this is a charset/encoding issue - although this doesn't solve > it. Good has special characters, Average and Poor do not. Changing Good to average displays it. But then I also have 'Male' in the same report which has a special character(a different one) and displays it. (all these problems are only in reportlab pdfs) > > Next, I would look at finding the difference between this report > and the > ones that work. Could it be that this report uses a different font, > which has problems with the special characters? all reports use the same font. And all the other reports display that particular problem character ok. And, just noticed that the same problem character that refuses Good uses appears in another part of the *same* report that doesnt display Good. Ok, so it is just that one line of code that is at fault - I will keep staring at it until I find whats bad about 'Good' - thanks for helping narrow it down. -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: baffling i18n problem after unicode update
Kenneth Gonsalves skrev: > On 20-Sep-07, at 4:42 PM, Werner F. Bruhin wrote: > > >>> other pdf reports. Not this particular one. I *know* there has to be >>> some very simple explanation for this - but cant for the life of me >>> find what it is. >>> >>> >> Does "Good" in Finish use some special characters? >> > > it does - but so do other words that are getting translated > successfully, and 'Good' itself is getting rendered properly in other > parts of the site and in other reports > Still, those other parts/reports may be doing something slightly different. I assume that the translations of "Average" and "Poor" are ascii. Try changing the translation of "Good" to something without special characters, and see if that helps. If it does, you at least know that this is a charset/encoding issue - although this doesn't solve it. Next, I would look at finding the difference between this report and the ones that work. Could it be that this report uses a different font, which has problems with the special characters? Nis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: baffling i18n problem after unicode update
On 20-Sep-07, at 4:42 PM, Werner F. Bruhin wrote: >> other pdf reports. Not this particular one. I *know* there has to be >> some very simple explanation for this - but cant for the life of me >> find what it is. >> > Does "Good" in Finish use some special characters? it does - but so do other words that are getting translated successfully, and 'Good' itself is getting rendered properly in other parts of the site and in other reports > > Maybe a problem with the encoding of the .po file, or no encoding > defined in it? encoding is utf-8 - which is standard for finnish. -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: baffling i18n problem after unicode update
Kenneth Gonsalves wrote: > there is only one .po file - Good, Poor and Average are all there. > Further, all three were working for the past year, only on update to > the unicode branch that this happened. I thought maybe Good was > marked as Fuzzy, but it is not - and anyway it translates fine in > other pdf reports. Not this particular one. I *know* there has to be > some very simple explanation for this - but cant for the life of me > find what it is. > Does "Good" in Finish use some special characters? Maybe a problem with the encoding of the .po file, or no encoding defined in it? Werner --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: baffling i18n problem after unicode update
there is only one .po file - Good, Poor and Average are all there.
Further, all three were working for the past year, only on update to
the unicode branch that this happened. I thought maybe Good was
marked as Fuzzy, but it is not - and anyway it translates fine in
other pdf reports. Not this particular one. I *know* there has to be
some very simple explanation for this - but cant for the life of me
find what it is.
On 20-Sep-07, at 1:59 PM, Bert Heymans wrote:
>
> Kenneth
>
> You most probably checked this but in the spirit of Ockham's Razor ...
> maybe you just don't have the translation for 'Good' filled in in the
> Finnish po file for that .py file but do have it translated for
> another context? That could explain why it shows up in some other
> places but not in the report.
>
> Just a guess :)
>
> Cheers,
> Bert
>
> On Sep 20, 5:03 am, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
>> hi,
>>
>> I have choices like this:
>>
>> HEALTH_CHOICES = (
>> ('G',_("Good")),
>> ('A',_("Average")),
>> ('P',_("Poor")),
>> )
>> my site is english and finnish. These choices are used in several
>> models. When finnish is on, they get translated in the web interface.
>> I also generate reports in reportlab. In one report, choices shows up
>> correctly if the report is in english. In finnish, the choice is
>> translated and prints if it is "Average" or "Poor" - but if the
>> choice is "Good", it does not appear in the report - it is blank. I
>> cant even begin to think how to solve this - it was ok before
>> updating to unicode. In all other reports with reportlab, "Good" gets
>> translated and shows up. Any ideas?
>>
>> --
>>
>> regards
>> kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/web/
>
>
> >
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: baffling i18n problem after unicode update
Kenneth
You most probably checked this but in the spirit of Ockham's Razor ...
maybe you just don't have the translation for 'Good' filled in in the
Finnish po file for that .py file but do have it translated for
another context? That could explain why it shows up in some other
places but not in the report.
Just a guess :)
Cheers,
Bert
On Sep 20, 5:03 am, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> hi,
>
> I have choices like this:
>
> HEALTH_CHOICES = (
> ('G',_("Good")),
> ('A',_("Average")),
> ('P',_("Poor")),
> )
> my site is english and finnish. These choices are used in several
> models. When finnish is on, they get translated in the web interface.
> I also generate reports in reportlab. In one report, choices shows up
> correctly if the report is in english. In finnish, the choice is
> translated and prints if it is "Average" or "Poor" - but if the
> choice is "Good", it does not appear in the report - it is blank. I
> cant even begin to think how to solve this - it was ok before
> updating to unicode. In all other reports with reportlab, "Good" gets
> translated and shows up. Any ideas?
>
> --
>
> regards
> kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/web/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
baffling i18n problem after unicode update
hi,
I have choices like this:
HEALTH_CHOICES = (
('G',_("Good")),
('A',_("Average")),
('P',_("Poor")),
)
my site is english and finnish. These choices are used in several
models. When finnish is on, they get translated in the web interface.
I also generate reports in reportlab. In one report, choices shows up
correctly if the report is in english. In finnish, the choice is
translated and prints if it is "Average" or "Poor" - but if the
choice is "Good", it does not appear in the report - it is blank. I
cant even begin to think how to solve this - it was ok before
updating to unicode. In all other reports with reportlab, "Good" gets
translated and shows up. Any ideas?
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
