I did some comments in my code, where I think we need to define what is right,
because the context is defined in XLIFF representation guide document.
Basically, we need to define a kind of standard to follow.

http://zuza.appspot.com/65/diff/1/6
File translate/convert/po2xliff.py (right):

http://zuza.appspot.com/65/diff/1/6#newcode52
Line 52: unit.createcontextgroup("po-1025", [("x-unknown", context)],
I think this should be done though a method. So we define a context group name
that match only this kind of context. I just use the example from the bug
description as base.

http://zuza.appspot.com/65/diff/1/4
File translate/convert/xliff2po.py (right):

http://zuza.appspot.com/65/diff/1/4#newcode46
Line 46: context = transunit.getcontextgroups('po-1025')
Here, the context should also be accessed though a method. Then we don't need to
worry about the context group name.
The hard thing about this is the name, there is no standard.

http://zuza.appspot.com/65/diff/1/3
File translate/storage/cpo.py (right):

http://zuza.appspot.com/65/diff/1/3#newcode517
Line 517: """Sets the current context for this unit"""
Should I care about the getcontext() ? The getcontext() also return the context
and KDE style comments (if I'm not wrong).
Maybe we should have an get_context_with_comments() method.

On 2008/07/24 05:14:27, georgeyk wrote:
> I did some comments in my code, where I think we need to define what is right,
> because the context is defined in XLIFF representation guide document.
> Basically, we need to define a kind of standard to follow.

Sorry. I mean, the context is *not* defined in XLIFF representation guide.

http://zuza.appspot.com/65/diff/42/72
File translate/storage/xliff.py (right):

http://zuza.appspot.com/65/diff/42/72#newcode264
Line 264: name += '-' + str(id(name))
As you noted, I'm not checking if this is a unique id or not.
I think this checking might be done in other bug, since a lot of unrelated
changes will be here. And we should define a good way to do this checking
(performance).