Re: [gentoo-portage-dev] portage-ng i18n?

Re: [gentoo-portage-dev] portage-ng i18n?

[Jason Mobarak]

On 18:14 Fri 26 Dec     , Spatz wrote:
> Current portage has all strings written in the code...
> To internationalize an application means it reads all strings (everything it 
> outputs to the screen/terminal/etc.) from an external file, depending on the 
> locale (gnu gives us gettext to get this done easily) and then outputs it, 
> the same way kde/gnome is being internationalized.
> 
> On Thursday 25 December 2003 00:07, Pieter Van den Abeele wrote:
> > I don't see any real problems. Could you be a little bit more exact of
> > what is lacking in current portage to achieve this?
> >
> > Pieter
> >

The current portage spec lists a component based design as goal for portage,
constructing an i18n emerge-like tool would present less difficulty if
portage-ng has a good component design.


-- 
-------------------------~
----------Jason-A-Mobarak-~
-aether-at-gentoo-dot-org-~
-------------------------~


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-ng i18n?

[foser]

On Tue, 2003-12-30 at 09:13, Jason Mobarak wrote:
> The current portage spec lists a component based design as goal for portage,
> constructing an i18n emerge-like tool would present less difficulty if
> portage-ng has a good component design.

For a front-end it would be easier, but to have all messages in the
components themselves i18n requires an effort from the very beginning.

- foser


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-ng i18n?

[Jason Stubbs]

On Thursday 08 January 2004 00:01, foser wrote:
> On Tue, 2003-12-30 at 09:13, Jason Mobarak wrote:
> > The current portage spec lists a component based design as goal for
> > portage, constructing an i18n emerge-like tool would present less
> > difficulty if portage-ng has a good component design.
>
> For a front-end it would be easier, but to have all messages in the
> components themselves i18n requires an effort from the very beginning.

Regardless of i18n, isn't it good design to have all user interaction done in 
one place? Specifically, shouldn't any messages/errors/etc be passed back to 
the user interface using exception-like mechanisms? Not only would it make 
i18n a lot easier, it doesn't inhibit possible uis.

--
Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-ng i18n?

[foser]

On Wed, 2004-01-07 at 17:01, Jason Stubbs wrote:
> Regardless of i18n, isn't it good design to have all user interaction done in 
> one place? Specifically, shouldn't any messages/errors/etc be passed back to 
> the user interface using exception-like mechanisms? Not only would it make 
> i18n a lot easier, it doesn't inhibit possible uis.

You want modules to pass their own messages back and forth, yes you can
probably use generic callbacks and fallback messages. But having all
messages (or interaction) in one place with a full plug-in system isn't
gonna work i think. Module writers probably do want to use their own
strings for specific messages.

- foser


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-ng i18n?

[Jason Stubbs]

On Thursday 08 January 2004 09:00, foser wrote:
> On Wed, 2004-01-07 at 17:01, Jason Stubbs wrote:
> > Regardless of i18n, isn't it good design to have all user interaction
> > done in one place? Specifically, shouldn't any messages/errors/etc be
> > passed back to the user interface using exception-like mechanisms? Not
> > only would it make i18n a lot easier, it doesn't inhibit possible uis.
>
> You want modules to pass their own messages back and forth, yes you can
> probably use generic callbacks and fallback messages. But having all
> messages (or interaction) in one place with a full plug-in system isn't
> gonna work i think. Module writers probably do want to use their own
> strings for specific messages.

Yeah, I guess, if user-interfaces need to be self-contained enough to be able 
to work with any support modules. Still, I think that some mechanism that 
forces module writers to not use embedded strings would be a good idea, 
though, even when modules are able to specify their own strings. Most (no?) 
module writers are able to internationalize into all languages, so it would 
be good if anybody could come along and easily do a translation.

I still think it would be a good idea for modules to be to refer to a set of 
predefined strings such as "Searching for ...", "... depends on ..." or 
whatever so that module writers have to worry about i18n as little as 
possible. It also makes for a more unified user interface.

--
Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-ng i18n?

[Jeremy Maitin-Shepard]

It seems it would make the most sense to use GNU gettext.  There is GNU
gettext support for a number of languages, including Bash, Python, Awk,
Java, and Perl, in addition to the obvious C and C++, and we could add
support to a portage-specific ebuild language if there comes to exist
such a language.  Any other solution would most certainly be more work
than GNU gettext.

-- 
Jeremy Maitin-Shepard

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-ng i18n?

[Paul de Vrieze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 08 January 2004 04:17, Jeremy Maitin-Shepard wrote:
> It seems it would make the most sense to use GNU gettext.  There is
> GNU gettext support for a number of languages, including Bash, Python,
> Awk, Java, and Perl, in addition to the obvious C and C++, and we
> could add support to a portage-specific ebuild language if there comes
> to exist such a language.  Any other solution would most certainly be
> more work than GNU gettext.

I don't know much about gettext, but I think it should be doable to have 
plugins being able to both define their own strings, and use standard 
messages like the ones mentioned. Possibly there could be a 
standard-strings module for the other modules to use. This module could 
then be used by other modules to get their localized strings.

Paul

- -- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQE//SpebKx5DBjWFdsRAtwcAJ9aOCMRlYVRXP6pAKBYF511RT1VQwCgv159
DgRmqKRrMPDTyTz1uY1IfQQ=
=wWI0
-----END PGP SIGNATURE-----


--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-ng i18n?

[Jeremy Maitin-Shepard]

Paul de Vrieze <pauldv@gentoo.org> writes:

> On Thursday 08 January 2004 04:17, Jeremy Maitin-Shepard wrote:
>> It seems it would make the most sense to use GNU gettext.  There is
>> GNU gettext support for a number of languages, including Bash, Python,
>> Awk, Java, and Perl, in addition to the obvious C and C++, and we
>> could add support to a portage-specific ebuild language if there comes
>> to exist such a language.  Any other solution would most certainly be
>> more work than GNU gettext.

> I don't know much about gettext, but I think it should be doable to have 
> plugins being able to both define their own strings, and use standard 
> messages like the ones mentioned. Possibly there could be a 
> standard-strings module for the other modules to use. This module could 
> then be used by other modules to get their localized strings.

I would recommend reading the GNU gettext info documentation.  It is
very informative.

-- 
Jeremy Maitin-Shepard

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] portage-ng i18n?

[Jeremy Maitin-Shepard]

Jason Mobarak <aether@gentoo.org> writes:

> The current portage spec lists a component based design as goal for portage,
> constructing an i18n emerge-like tool would present less difficulty if
> portage-ng has a good component design.

There might be advantages to a `component-based design' (obviously that
phrase is subject to diverse interpretation), but I do not see how ease
of internationalization is one such particular advantage.

-- 
Jeremy Maitin-Shepard

--
gentoo-portage-dev@gentoo.org mailing list