[FOSS-GPS] More upcoming FoxtrotGPS releases, and...

[Joshua Judson Rosen]

Joshua Judson Rosen <rozzin at geekspace.com> writes:
>
> Timo Jyrinki <timo.jyrinki at gmail.com> writes:
> [...]
> > Other than that, please merge one-liner at (bzr)
> > lp:~timo-jyrinki/+junk/foxtrotgps-intltoolfix that fixes running
> > intltool-update (without the need to configure/make the software) that
> > the translators usually rely on.
> 
> I saw this when I was going through the patches that you and Daniel
> had put together in the Debian package, and pushed up a slightly different
> change to prevent `intltool-update --maintain' from failing (I added
> foxtrotgps.glade.in to POTFILES.skip) a couple of weeks ago;
> 
> It still requires running `./configure' so that the "@PACKAGE_NAME@"
> and "@PACKAGE_VERSION@" placeholder-strings (and whatever other similar
> things might end up in there, I guess--I can't think of any right now)
> are replaced with the correct, translatable English strings, but it
> shouldn't require a `make' cycle.

Actually, upon closer inspection I realise that this isn't actually
the same change as you made in the Debian patch: there you were *adding*
foxtrotgps.glade.in to POTFILES.in, and here you're actually *replacing*
foxtrotgps.glade with foxtrotgps.glade.in as the source of translatable
strings. The way that things are setup right now, it seems like that
would actually cause some problems (and it explains where some of
your fuzzies came from):

The way it works right now is that foxtrotgps.glade.in is processed
by ./configure (or possibly by ./config.status, possibly as a result
of running `make', after there's been a successful configure)
to produce foxtrotgps.glade, writing the actual package-name and
package-version where there are placeholders in the `.in' file; then
intltool processes the gladefile that's output, after the substitutions.
If intltool processes the `.in' file instead, then you're going to be
translating strings containing "@PACKAGE_NAME@" rather than "FoxtrotGPS"
(or whatever name, if the package has been re-branded), and
"@PACKAGE_NAME@" isn't what gettext is going to see at runtime....

The reason that I have a foxtrotgps.glade.in that's processed by configure,
of course, is because I want it to be as easy as possible to re-brand
the package, and I don't really have any better ideas for how to do that,
so far :(

It's tempting to try to write the translatable strings in terms
of "%s", with the package-name, etc. to be inserted at runtime;
but that idea has issues of its own.

After further thought, I also realise that my initial response
of `you still need to configure, but you don't need to build' may
actually be rather silly: in order to configure, you need to have
setup all of the same dependencies as would be required to build--
ensuring that the build is going to work if tried is mostly the reason
for running configure, after all (and that's in the list of issues
that we've addressed in FoxtrotGPS--that if `./configure' works, 
then `make' shouldn't barf like it used to). So, I guess the bigger part
of `needing to configure and make', for you, is technically not `make'
 per se but rather `configure', right?

I'm not quite sure that I actually understand even the premise of
`being able to translate without building', though--don't translators
need to run-test their translations, much like programmers test code? :)

Or is there a process by which translators do run-test without building?

I'm imagining the possibility of issues like a new translation being
a different length than expected and not fitting into the GUI widgets
properly, or a translation in a right-to-left language like Hebrew
or Arabic showing left-to-right assumptions in the GUI design that
don't hold true, or some other issue where some assumption in the code
turns out to be wrong in some locale. Am I just assigning too much
weight to these issues? Am I just mistaken to be worrying about them?
It'd be nice if I'm mistaken, actually :)

(I really would like to see an Arabic or Hebrew or other right-to-left
translation--there are some parts of the GUI where I wonder
if it would `work' in that context...)

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."