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

[Joshua Judson Rosen]

Timo Jyrinki <timo.jyrinki at gmail.com> writes:
>
> 2010/8/29 Joshua Judson Rosen <rozzin at geekspace.com>:
> > > 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)
> 
> Ok, that's right, with that usage one couldn't use the .in file as a
> source of strings. So indeed the suggestion was wrong at least as long
> as those are used.
> 
> > 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 :(
> 
> Well the runtime via %s is the usual way.
> 
> > So, I guess the bigger part
> > of `needing to configure and make', for you, is technically not `make'
> > per se but rather `configure', right?
> 
> Yes, make is only a time consumption, configure is the one where you
> need the actual development environment.
> 
> > 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?
> 
> Yes. msgfmt -c -v fi.po ; mv messages.mo
> /usr/share/locale/fi/LC_MESSAGES/foxtrotgps.mo ; foxtrotgps

Seeing as that method mostly limits testing (and work?) to version
that has already been released, perhaps the requirements there would
be sufficiently met by shipping the .glade file in our (tarball) releases?
It looks like I should make that change anyway, if we keep the
`.glade is generated from .glade.in' architecture, since not shipping
the .glade is causing `make distcheck' to fail....

Though, if everyone else has found that doing piecemeal substitution
with "%s" actually tends to work fine in practice..., everyone else's
real-world experience beats my conjecture and I'm willing to concede. ;)

I can handle putting "%s" into the strings in the glade file, and
having a few lines in the code that fetches those strings from the
widgets in their initial state, does the substitutions, and then
writes the (substituted+translated) strings back into the live widgets
at runtime. e.g.: the main window's title becomes "%s" in the glade file
and has a translation of "FoxtrotGPS" substituted-in at runtime; likewise,
the version-string becomes "%s %s", and the checkbox-label that reads
"add photos to the FoxtrotGPS database" string becomes
"add photos to the %s database".

Does that sound right, to you?

cf.: http://www.hackerposse.com/~rozzin/foxtrotgps/branches/intl-cleanup

> If the string changes from last, eg. packaged release are not
> something that must be seen in the actual UI to be completely
> understood in context, it's often enough just to review the PO file
> itself (with experience it becomes easier to estimate when true UI
> testing is needed).

Mmm--yes.

> On the other hand, deciding if the need to run ./configure is a
> problem or not depends wholly on the level of technical skills of the
> potential translators. Of course I have development environment and
> can understand inltool-update error being caused by lack of
> ./configure,

And it's nice to have someone like you, who can understand enough of
both worlds to bridge them and `keep us honest'. :)

> but there are potentially people who think it's simply
> broken. But I actually don't have much idea what's the percentage of
> these translator people who do know how to edit PO files via version
> control systems (opposed to using Launchpad, Transifex or others) but
> who give up if development environment is needed. It might be a
> complete non-issue as well, so I wouldn't worry too much about that...

Well, if there's no real gain and I'm just making people's lives
difficult and being weird for the sake of it..., I guess I can see
why some people might call that `simply broken'.

> > 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 :)
> 
> In case of FoxtrotGPS at least the string length might be an issue.
> But as a rule of thumb, if one manages to achieve equal or less than
> the English string in length, then it doesn't need to be thought
> about. So it's again easiest just to try that or abbreviate if
> necessary.

Ah--interesting point.

> > (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...)
> 
> Yes, there might been places where the string should be constructed
> more with %s used, so that the %s could be placed eg. on the left.

I was actually wondering more about some of the GUI-layout mechanisms
that are being used (box-packing vs. table-layout), and which would
switch over to flowing right-to-left (where in English the first item
packed into a horizontal box should be on the left and additional items
should proceed to the right, it's exactly opposite in Hebrew);
it just occurred to me that I could probably just try it even without
any text-translations in place..., and it looks like GTK+ does convert
both the box-packing (which I expected) and the `table' attachments
(which I wasn't so sure about) to match the text-direction. Nice.

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