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

[Timo Jyrinki]

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

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).

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, 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...

For more potential translators, opening the translations section in
Launchpad to Launchpad Translators language groups is a possibility as
always.

> 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.

> (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.

-Timo