Joshua Judson Rosen <[email protected]> writes: > > Timo Jyrinki <[email protected]> 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))))." _______________________________________________ This message is sent to you from [email protected] mailing list. Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
