Re: Gnats{web} localization

[Chad Walstrom]

Mike M. Volokhov wrote:
> Very nice idea! I seen something on TODOs, but you have explained this
> for me, thanks. Is this work available anywhere for tests?

That is up to Mel.  He's set up on savannah as a developer, so he can
create branches off the trunk CVS repository.  I suspect he's busy, as
is everyone.

> > as to which we should pursue.  I don't know how large of an impact #1
> > would have on the code base, as I'm not that familiar with it yet.
> 
> The GNATS have clear enough API and I think this feature can be added
> within minimal work. However, it will depends on two libraries more:
> iconv and MIME. But again, IMHO it cost this.

The MIME library should be considered in any case.  We need to clean up
how queue-pr handles incoming emails and how gnatsd constructs outgoing
emails.  This could be part of the front-end abstraction you were
speaking of.

> If you approve this work I'll start coding and will publish patches
> ASAP just after finishing.

I'm definitely open to accepting patches.  If you would like, I can add
a task in the TODO list for l12n and i18n for you.  We may target this
for 4.2 or 5.0.  If you want CVS access, please submit a request via the
savannah project page to become a member.  To work on the CVS itself,
create a branch off the trunk for your project or submit patches through
the savannah patch page.

> > #2 probably won't happen until we get Mel's new API in place.
> 
> Yep, it is. Moreover, charset or language specification is needed in
> any case. If new API could handle arbitrary "frontend" (i.e. input PR
> format) too, then it would be possible to submit XML reports within
> any charset (or even any charset for parts of PR).

Yes.  I've been thinking about this as well.  send-pr, edit-pr, and
possibly pr-edit could be merged into one application, as they share a
lot of similarities.  pr-edit does the heavy-lifting and send-pr and
edit-pr are simply shell wrappers around it.

The send-pr shell script already tries to take advantage of queue-pr and
pr-edit if they're available, so it's suffering from feature creap and
stressing the fragility of sh.  A C program may be the next step for
these applications, where an abstracted frontend API would be
appropriate.

In fact, breaking out the protocol, back-end API and front-end API into
a library(s) of its(their) own might be useful.

> Will be waiting for Mel H.

O.K.

-- 
Chad Walstrom <address@hidden>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

signature.asc
Description: Digital signature