Book reports have problems with filters that contain non-ASCII characters

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Book reports have problems with filters that contain non-ASCII characters

Julio Sánchez-2
Hello,

When a filter name contains accented characters, either because it
translated to a text with accented letters or it contains the name of
a person containing accented letters, I get a key error on the filter
name that seems to be fixed by the following patch:

Index: GenericFilter.py
===================================================================
RCS file: /cvsroot/gramps/gramps2/src/GenericFilter.py,v
retrieving revision 1.85.2.20
diff -u -r1.85.2.20 GenericFilter.py
--- GenericFilter.py 26 Jun 2005 20:55:49 -0000 1.85.2.20
+++ GenericFilter.py 27 Jun 2005 14:00:20 -0000
@@ -2296,14 +2296,14 @@
             cnt += 1
         
         for filt in SystemFilters.get_filters():
-            self.store.append(row=[_(filt.get_name())])
+            self.store.append(row=[filt.get_name()])
             self.map[filt.get_name()] = filt
             if default != "" and default == filt.get_name():
                 active = cnt
             cnt += 1
 
         for filt in CustomFilters.get_filters():
-            self.store.append(row=[_(filt.get_name())])
+            self.store.append(row=[filt.get_name()])
             self.map[filt.get_name()] = filt
             if default != "" and default == filt.get_name():
                 active = cnt
@@ -2324,7 +2324,7 @@
         active = self.get_active()
         if active < 0:
             return None
-        key = self.store[active][0]
+        key = unicode(self.store[active][0])
         return self.map[key]
 
 
The last change fixes the problem. The other two changes are
debatable.  On the one hand, it seems unlikely that there is a
translation for custom filter names.  On the other hand, if there was,
the value remembered in self.store would not match the one needed for
self.map so if a translation happened to exist, the code would break
with Key error later when accessing self.map.

Does this make sense?

May I commit this fix?

Regards,

Julio


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Book reports have problems with filters that contain non-ASCII characters

Don Allingham
Julio,

The unicode conversion looks correct. We've had problems with
gtk.ListStores not properly returning unicode values in the past.

Using the _() call on the filter name doesn't help. A custom filter name
will be determined by the user at run time, and all translatable strings
 are fixed at this point.

It also doesn't buy us anything, since the custom filters are local to
the person who created it, so converting it to a different language
doesn't provide any benefit.

Go ahead and commit the unicode conversion, but I would pass on the
translation of filter names.

Don


Julio Sanchez wrote:

> Hello,
>
> When a filter name contains accented characters, either because it
> translated to a text with accented letters or it contains the name of
> a person containing accented letters, I get a key error on the filter
> name that seems to be fixed by the following patch:
>
> Index: GenericFilter.py
> ===================================================================
> RCS file: /cvsroot/gramps/gramps2/src/GenericFilter.py,v
> retrieving revision 1.85.2.20
> diff -u -r1.85.2.20 GenericFilter.py
> --- GenericFilter.py 26 Jun 2005 20:55:49 -0000 1.85.2.20
> +++ GenericFilter.py 27 Jun 2005 14:00:20 -0000
> @@ -2296,14 +2296,14 @@
>              cnt += 1
>          
>          for filt in SystemFilters.get_filters():
> -            self.store.append(row=[_(filt.get_name())])
> +            self.store.append(row=[filt.get_name()])
>              self.map[filt.get_name()] = filt
>              if default != "" and default == filt.get_name():
>                  active = cnt
>              cnt += 1
>  
>          for filt in CustomFilters.get_filters():
> -            self.store.append(row=[_(filt.get_name())])
> +            self.store.append(row=[filt.get_name()])
>              self.map[filt.get_name()] = filt
>              if default != "" and default == filt.get_name():
>                  active = cnt
> @@ -2324,7 +2324,7 @@
>          active = self.get_active()
>          if active < 0:
>              return None
> -        key = self.store[active][0]
> +        key = unicode(self.store[active][0])
>          return self.map[key]
>  
>  
> The last change fixes the problem. The other two changes are
> debatable.  On the one hand, it seems unlikely that there is a
> translation for custom filter names.  On the other hand, if there was,
> the value remembered in self.store would not match the one needed for
> self.map so if a translation happened to exist, the code would break
> with Key error later when accessing self.map.
>
> Does this make sense?
>
> May I commit this fix?
>
> Regards,
>
> Julio



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Book reports have problems with filters that contain non-ASCII characters

Julio Sánchez-2
2005/6/27, Don Allingham <[hidden email]>:
> Julio,
>
> The unicode conversion looks correct. We've had problems with
> gtk.ListStores not properly returning unicode values in the past.

Great.  Will do.

> Using the _() call on the filter name doesn't help. A custom filter name
> will be determined by the user at run time, and all translatable strings
>  are fixed at this point.
>
> It also doesn't buy us anything, since the custom filters are local to
> the person who created it, so converting it to a different language
> doesn't provide any benefit.
>
> Go ahead and commit the unicode conversion, but I would pass on the
> translation of filter names.

I was removing translation, not adding it.  What I was proposing is to
lose the half-done translation present there.  At best, as you very
well explain, it's useless.  But, since it is half-done, if it ever
had any effect by chance, it would be harmful because it would store
the translated in the ListStore but the untranslated string in
self.map.  Then the retrieved value from the ListStore would not match
any of the stored keys in self.map.

Unless there is something I have not understood, that is,...

Regards,

Julio


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Book reports have problems with filters that contain non-ASCII characters

Don Allingham
Julio,

Sorry, I misread your message.

Go ahead and commit the full patch. Let's remove the half-done translation.

Don

Julio Sanchez wrote:

> 2005/6/27, Don Allingham <[hidden email]>:
>
>>Julio,
>>
>>The unicode conversion looks correct. We've had problems with
>>gtk.ListStores not properly returning unicode values in the past.
>
>
> Great.  Will do.
>
>
>>Using the _() call on the filter name doesn't help. A custom filter name
>>will be determined by the user at run time, and all translatable strings
>> are fixed at this point.
>>
>>It also doesn't buy us anything, since the custom filters are local to
>>the person who created it, so converting it to a different language
>>doesn't provide any benefit.
>>
>>Go ahead and commit the unicode conversion, but I would pass on the
>>translation of filter names.
>
>
> I was removing translation, not adding it.  What I was proposing is to
> lose the half-done translation present there.  At best, as you very
> well explain, it's useless.  But, since it is half-done, if it ever
> had any effect by chance, it would be harmful because it would store
> the translated in the ListStore but the untranslated string in
> self.map.  Then the retrieved value from the ListStore would not match
> any of the stored keys in self.map.
>
> Unless there is something I have not understood, that is,...
>
> Regards,
>
> Julio
>




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Book reports have problems with filters that contain non-ASCII characters

Julio Sánchez-2
Dan,

It is done now.

Regards,

Julio

2005/6/27, Don Allingham <[hidden email]>:

> Julio,
>
> Sorry, I misread your message.
>
> Go ahead and commit the full patch. Let's remove the half-done translation.
>
> Don
>
> Julio Sanchez wrote:
> > 2005/6/27, Don Allingham <[hidden email]>:
> >
> >>Julio,
> >>
> >>The unicode conversion looks correct. We've had problems with
> >>gtk.ListStores not properly returning unicode values in the past.
> >
> >
> > Great.  Will do.
> >
> >
> >>Using the _() call on the filter name doesn't help. A custom filter name
> >>will be determined by the user at run time, and all translatable strings
> >> are fixed at this point.
> >>
> >>It also doesn't buy us anything, since the custom filters are local to
> >>the person who created it, so converting it to a different language
> >>doesn't provide any benefit.
> >>
> >>Go ahead and commit the unicode conversion, but I would pass on the
> >>translation of filter names.
> >
> >
> > I was removing translation, not adding it.  What I was proposing is to
> > lose the half-done translation present there.  At best, as you very
> > well explain, it's useless.  But, since it is half-done, if it ever
> > had any effect by chance, it would be harmful because it would store
> > the translated in the ListStore but the untranslated string in
> > self.map.  Then the retrieved value from the ListStore would not match
> > any of the stored keys in self.map.
> >
> > Unless there is something I have not understood, that is,...
> >
> > Regards,
> >
> > Julio
> >
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel