Re: [Translate-devel] Considerations about Placeables support in Translate Toolkit

[F W. <fr...@tr...>]

On Di, 2008-07-22 at 19:33 +0200, Enrique G. Paredes wrote:
> Hello everybody.
> 
> Thank you for all your comments, really.
> 
> I have removed the unnecessary commented statements and updated the
> copyright declarations, thanks for the tip, Friedel. The properties
> have been activated and the __str__() function has been reimplemented
> to follow the suggestions. I haven't tested it yet, but it shouldn't
> fail in the case Friedel has pointed out, when self.content is
> non-ascii data ("For objects which don't have a particular
> representation for human consumption, str() will return the same value
> as repr()" - Python tutorial chapter 9).

I would really like it if you test it. The str() function needs a way to
know how to convert it to a string, and every string has an encoding. We
need to know it works with non-ascii values, otherwise it basically
doesn't work :-)


> >> For example, for this XLIFF source element:
> >>
> >>     <source>Welcome to <ph>${product_name}</ph>.<ph
> >> equiv-text="(C)">/copyright</ph> Sam &amp; Max Enterprises</source>
> >>
> >> the plain source obtained with the getsource() method (".source" property) is:
> >>
> >>     source =  "Welcome to ${product_name}./copyright Sam & Max Enterprises"
> >>
> >> and the marked version obtained with the getmarkedsource() method is:
> >>
> >>     markedsource =  ['Welcome to ', "<Placeable [ctype='None',
> >> equiv-text='None'] content='${product_name}'>", '.', "<Placeable
> >> [ctype='None', equiv-text='(C)'] content='/copyright'>", ' Sam & Max
> >> Enterprises']
> >
> >
> > Ok, I am curious to hear what other people think about this. My initial
> > suggestion was only slightly different. I was thinking about 2-tuples
> > containing the string, and then the placeable object. The reason for
> > this is that I am trying to think of a design that makes this as useful
> > as possible for other applications as well. For example: diffing the old
> > and new source strings (so each part of the string could be provided in
> > a list, with "diff" objects instead of placeable objects. This could
> > soon become relevant with George's work on previous msgids.
> >
> > I think it will be nice if the strings from these tuples can be
> > concatenated to for the .source(). So for your example:
> >
> > markedsource = [('Welcome to ', None), ("${product_name}", <Placeable
> > [ctype='None', equiv-text='None']), ('.', None), ("/copyright",
> > <Placeable [ctype='None', equiv-text='(C)']>"), (' Sam & Max
> > Enterprises', None)
> >
> > None here indicates a "normal" string. I don't think this is such an
> > important issue, but I'm just mentioning my idea.
> 
> If you think that it's more convenient to return the list of tuples, I
> can change it without problems. However,  I'm not complety sure about
> this, I agree with you that is more comfortable to work with the
> tuples (string, placeable) but there is some kind of redundancy
> duplicating the content string. Other option may be to give an easy
> way to build the list of tuples when needed. For example, if the
> __str()__ function is reimplemented to return only the content string,
> it will be really easy to build the tuples list from the current
> markedsource list with a list expansion expression. The current
> __str__() may be move to __repr__() as it is useful for debugging
> purposes. What do you think about this?

We don't need to duplicate it in the content if we move it out, of
course. Moving it out might not work well if the placeable doesn't have
access to its own string, but in Python at least this won't consume much
extra memory.

I guess my idea just makes it easy to use an iterated string even if the
using code isn't that familiar with placeables. If we can have a similar
API for different types of string iterations, I think this will help
programmers to move between parts of the Toolkit.

Unless there are further comments on this, we can probably go with
anything - I don't think it is important enough to labour the pint
further.

Friedel