[Freeipa-devel] [PATCH] 0087 Warn about DNA plugin configuration when working with local ID ranges

[Alexander Bokovoy]

On Wed, 17 Oct 2012, Martin Kosek wrote:
>On 10/17/2012 12:42 PM, Alexander Bokovoy wrote:
>> On Wed, 17 Oct 2012, Petr Viktorin wrote:
>>> On 10/17/2012 12:10 PM, Alexander Bokovoy wrote:
>>>> On Wed, 17 Oct 2012, Sumit Bose wrote:
>>>>> On Wed, Oct 10, 2012 at 12:59:53PM +0300, Alexander Bokovoy wrote:
>>>>>> On Wed, 10 Oct 2012, Sumit Bose wrote:
>>>>>>> On Wed, Oct 10, 2012 at 10:51:11AM +0300, Alexander Bokovoy wrote:
>>>>>>>>
>>>>>>>> Warn about manual DNA plugin configuration when working with local
>>>>>> ID ranges
>>>>>>>> since we currently do not support automatic pick up of the changed
>>>>>>>> settings for local ID ranges by the DNA plugin.
>>>>>>>> https://fedorahosted.org/freeipa/ticket/3116
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> / Alexander Bokovoy
>>>>>>>
>>>>>>>> """)
>>>>>>>
>>>>>>> I wonder if we should add a sentence like "See section 'Managing Unique
>>>>>>> UID and GID Number Assignments' in the FreeIPA Documentation for
>>>>>>> details' to point the admin to the right directory? Or replace the last
>>>>>>> sentence with something more explicit like 'The dnaNextRange attribute
>>>>>>> of 'cn=Posix IDs,cn=Distributed Numeric Assignment
>>>>>>> Plugin,cn=plugins,cn=config' has to be modified to match the new
>>>>>> range'?
>>>>>> Updated the patch, also adding the same warning to the 'idrange-add'
>>>>>> help.
>>>>>>
>>>>>> --
>>>>>> / Alexander Bokovoy
>>>>>
>>>>> ACK.
>>>>>
>>>>> If there is an easy way to avoid the duplication it would be nice if you
>>>>> can modify the patch accordingly.
>>>> Docstring is a string literal only:
>>>>    >>> s="""text
>>>>    ... first
>>>>    ... second"""
>>>>    >>> def f():
>>>>    ...   """another text
>>>>    ...      first
>>>>    ...      second"""+s
>>>>    ...   return
>>>>    ...    >>> print f.__doc__
>>>>    None
>>>>    >>> def y():
>>>>    ...   """Doctstring for y()"""
>>>>    ...   return
>>>>    ...
>>>>    >>> print y.__doc__
>>>>    Doctstring for y()
>>>>    >>>
>>>>
>>>> Though we could play the game and do explicit     f.__doc__ = s
>>>> this would work but...
>>>>
>>>> Any preference from others?.
>>>
>>> In the code you changed, we already play that game.
>> No, we don't. We do explicit string literals wrapped into Gettext()
>> calls but it does not change the fact that they are still literals and
>> xgettext does not support arbitrary expressions in Python code.
>>
>> I tried two different approaches:
>> 1.   a = _("""one text""")
>>   __doc__ = _("""another text""") + a
>>
>> 2.   a = """one text"""
>>   __doc__ = _("""another text""" + a)
>>
>> Both don't work. First is because Gettext() class does not support
>> concatenation. Second one is because xgettext does not work with such
>> form and only takes """another text""".
>>
>
>I think I still do not get it, what's wrong with my example?
>
># python
>>>> from ipalib import _
>>>> a = """Bonus text"""
>>>> __doc__ = _("""Another Text""" + a)
>>>> __doc__
>Gettext('Another TextBonus text', domain='ipa', localedir=None)
>>>> unicode(__doc__)
>u'Another TextBonus text'
>
>Am I missing something?
Yes. You are missing xgettext utility. It does extract strings for
translation. In your example it would extract """Another Text""" only,
because it does not support evaluation of expressions.

More to that, the actual code would ask then for translated string with
msgid """Another TextBonus text""" which does not exist in the
translation catalog at all. This means whatever was translated for
"""Another Text""" will never be shown.


We need to make Gettext() class additive, so that when two Gettext()
instances are added, they accumulate msgid(s) and then do concatenation
of translated entries on __str__.

-- 
/ Alexander Bokovoy