im-chooser and system-config-httpd

[Jeremy Katz]

On Mon, 2007-09-24 at 02:13 +0100, Dimitris Glezos wrote:
> Στις 23-09-2007, ημέρα Κυρ, και ώρα 20:18 -0400, ο/η Jeremy Katz έγραψε:
> > On Sat, 2007-09-22 at 07:33 +0100, Dimitris Glezos wrote:
> > > Στις 21-09-2007, ημέρα Παρ, και ώρα 13:07 +0200, ο/η Adam Pribyl έγραψε:
> > > > The last question which is still not clear to me - how's that with those 
> > > > minus sings and exclamation marks in 
> > > > http://translate.fedoraproject.org/languages/cs/fedora-8
> > > > What should I do with them? Or should they be ignored?
> > > 
> > > Those are problems and warnings of the international support of the
> > > module, and the developer should know about them. So usually someone
> > > needs to open a bug report to the package and let the maintainer know
> > > about them to fix them.
> > > 
> > > Most of them are created because the modules don't use intltool for
> > > extraction of the strings.
> > 
> > FWIW, the fact that transifex's status is dependent on the usage of
> > intltool is, IMHO, a bug.
> 
> Transifex can handle both of them equally OK; the problem is with Damned
> Lies (the statistics app, which we are not upstream).

Yeah, sorry for the imprecision

> DL supports intltool-based string extraction better than other methods,
> simply because upstream (GNOME) doesn't have many (any?) modules which
> don't use intltool.

Doubtful that they really have any at this point.

> > It basically forces people to use the GNOME
> > stack as well as autotools for their project when there's really not a
> > good reason to do so.  There are definitely better build systems out
> > there...
> 
> +1 to have the choice.
> 
> The easiest solution right now would be to go ahead and add the choice
> in the XML file, so that the viewing template will know and hide the
> relevant warnings for non-intltool modules.

Well, it should be easy enough to auto-figure out if intltool is being
used or not.  iirc, intltool depends on POTFILES.in so if it doesn't
exist, then no intltool and hide the warnings

> There would be other issues to solve then (which languages are active?
> Are all strings there? etc), which I don't know how standardized our
> i18n is (same variable in all Makefiles?) in order to automate the
> process and *do* present some warnings (eg. for languages not shipped).

This is going to vary from build system to build system.  And this is a
place where we can take advantage of the fact that we're building a
binary distribution -- just look in the packages to see what's there.  

Trying to support what every build mechanism might support just feels
like it's going to get out of hand.  Especially when you take into
account custom makefiles, etc.

Jeremy