John Rice-san wrote (10/31/08 10:04 AM):
> Fujiwara - we are going to RC1 next Monday and I would really like to
> bring this to a resolution or I will not get l10n support in for PM and
> UM for 2008.11, nor will I get the doc support landed.
Yes, probably I also think RC1 is better as I think this is a stopper.
>
> Are you saying that we must use the GNU gettext support to get the
> translation support needed for globals via N_ and the intl tool?
> So if we are using it in this instance you are saying we should use it
> consistently across all of the code base. The other issue being that if
> we do need to swap domains we can with this api and not the other class
> based one.
>
> Its one argument, but I would favor simplicity every time over a
> possible future requirement.
Yes, N_ is needed because if the strings are not marked with N_(), the strings
are not retrieved as translatable. I think it's an usual way to involve
external many community.
I also expect the global strings are not many.
I'm not sure what you mean in the second issue. The N_ doesn't use any domains
and it can be classed, e.g. this.N_
I'm not sure your concern. If the common part exists, probably config.py or
init.py could be included.
>
> When you say "install() has a problem to disable the compatibility of C
> gettext()." Why is this a problem for us? When would we want to disable
> it? Can you give me a concrete example in the code please, I do not
> understand what you are saying.
I'm suggesting to use gettext.textdomain() as it should be better.
The problem is to consist the usage in the codes.
Otherwise, why is it a problem to follow textdomain()/bindtextdomain()?
If we don't consist the gettext usage, I think there is no problem in this
thread.
I think I have already shown the example. It's not an IPS code.
>
> I would vote along with Danek for using gettext.install and keeping
> things simple in the code. If at some stage down the line we do need to
> access the domain we can use the GNU gettext API, but until we need to
> we should stick with gettext.install().
>
> Please take the webrev I created with your various mods and modify it so
> it only uses gettext.install(). If this is not possible please explain
> in detail why.
OK, could you explan what is your suggestion exactly?
Do you mean to use gettext.install in client.py only?
e.g. packagemanager.py already has self._ . I think removing self in all
strings(e.g. self._("foo")) and using gettext.install() don't set domain
correctly.
gtk.glade doesn't have install() and using gettext()/textdomain() is the common
way between gettext and gtk.glade.
>
> http://cr.opensolaris.org/~jmr/pm_4126_v4_Oct30/
>
> If you have a specific instance such as the use of globals that needs
> the GNU gettext API, please add in support for this only with a comment
> explaining why this is needed in this instance. If the code can be
> reworked to remove this dependency on the globals all the better.
I think your suggestion need to be clarified above before we work it.
>
> If this approach is not possible as when using gettext.install "Other
> things break", please give us a detailed breakdown of what will break
> and why, so we can better understand what you are trying to achieve and
> work around.
Hmm.., probably we may be in loop.
My suggestion is textdomain/bindtextdomain and yours is install.
I explained why textdomain/bindtextdomain is better(textdomain(None)) but I
don't see why install is better.
The break point is to loose the consistency if we want to consist the usage of
gettext in IPS.
On the other hand, I don't think any other things break when
textdomain/bindtextdomain is used.
Do we really need to consist the codes as generally I recommend
textdomain/bindtextdomain?
Thanks,
fujiwara
>
> Thanks,
>
> JR
>
>
> Danek Duvall wrote:
>> On Fri, Oct 31, 2008 at 03:54:52AM +0900, Takao Fujiwara - Tokyo S/W
>> Center wrote:
>>
>>
>>> I'm not convinced you have a proper reason to use gettext.install.
>>> Other things break - they would be just easy bugs.
>>>
>>
>> What are those things?
>>
>>
>>> gettext.install is not a class based too.
>>>
>>
>> Yes it is.
>> Danek
>>
>
>
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
