GNOME Bugzilla – Bug 358495
support for multiline scheme strings
Last modified: 2012-03-16 12:40:17 UTC
the beast project needs to be able to translate multiline scheme strings in guile scripts which are marked up like e.g. this (short variants for brevity in the report): (N_ "This script creates a new Mixer Bus for each track in the " "song that is currently using the Master Bus as output.") (_ "The loop range of the specified song contains no parts " "or is unset, so no parts can be identified to operate on.") in order to make this happen, it patches intltool-extract.in to support a new tranlation type scm-funcs and then marks files POTFILES.in accordingly: [type: gettext/scm-funcs] library/scripts/mixer-splitup-by-track.scm [type: gettext/scm-funcs] library/scripts/modules2grid.scm the scheme support that was found in intltool was unusable for beast for a variety of reasons: - the only markup supported was that used by gimp: _("foo") which isn't even valid scheme syntax and thus could not be made to work with standard scheme implementations like guile (you'd have to write your own non-R5RS interpreter for this). - multi string markup was not supported: (_ "string1" "string2") - comments and line numbers were not preserved when parsing the strings like they are when C sources are parsed.
Created attachment 73698 [details] [review] patch used by the beast project for scm-funcs support this patch does 2 things: 1) it introduces a new mode to message()/convert() in which the the input files is taken, translated to C syntax (as far as comments, line numbers and i18n string markup is regarded at least) and then the output of which is run through gettext as normal C source code. 2) it implements a state machine that takes scheme syntax as input and produces C style output as far as comments, i18n string markup and line numbers are regarded. this patch extends intltool-extract.in good enough for beast to provide the same level of i18n support for scheme scripts that it provides for C. as for why the support was implemented like presented in the patch: (1) is implemented to allow full featured i18n string parsing, including support for multiple strings within parenthesis as well as preserving of accurate line number informatoin and source code comments. (2) having a state automaton to translate scheme strings may seem as a stretch at first, but because it's a fairly thoroughly documented state machine with a pretty clearly defined scope it was moderately easy to implement and maintain.
I remember having this discussion, but don't remember it ending with a committable patch, and have later forgot about it (it might still be marked "important" in my mail folder, but there are hundreds of other messages in there as well :(). I see that you took the suggestion I gave at the time: implement a new mode to maintain compatibility with Gimp (instead of replacing current scm mode). Will be looking into patch soon.
Tim, sorry for taking so long (I guess GUADEC is the right time to handle some patches). I looked at the patch, I don't have too many problems with it, except for the fact that you actually change entire behaviour for this mode just to get the real line numbers, if I am not mistaken? It makes it harder to maintain, and easier to make a mistake (for example, you don't seem to be outputting xgettext:no-c-format comment when there's a percent in the string which is not c-formatted: this commonly causes problems for translators). So, I feel it's not worth the bother maintaining very similar logic in two places (msg_write() and transform_scm_funcs()) just for the line numbers, when they are not correct for most other intltool supported files. Not that having correct line numbers wouldn't rock, but you'd still get the wrong filenames with your approach, so I don't see the benefit. Of course, having a regression test would be very welcome, and I am sure you already got some interesting files in beast which can be added to tests/.
(In reply to comment #3) > Tim, sorry for taking so long (I guess GUADEC is the right time to handle some > patches). > > I looked at the patch, I don't have too many problems with it, except for the > fact that you actually change entire behaviour for this mode just to get the > real line numbers, if I am not mistaken? no, my patch doesn't change behavior, it introduces a new mode. on a isde note, i do however thing that you badly need to change your scheme parsing. your current "scheme" mode parses syntax constructs like this: _("string") which is C calling convention and not valid scheme syntax - and never will be, see: http://www.schemers.org/Documents/Standards/R5RS/ scheme function calls use this syntax: (function arg0 arg1 moreargs) nevertheless, my patch doesn't touch your current scheme parsing mode, it introduces a new mode "scm-funcs" that takes real scheme functions as input. > It makes it harder to maintain, and easier to make a mistake (for example, you > don't seem to be outputting xgettext:no-c-format comment when there's a percent > in the string which is not c-formatted: this commonly causes problems for > translators). So, I feel it's not worth the bother maintaining very similar > logic in two places (msg_write() and transform_scm_funcs()) just for the line > numbers, when they are not correct for most other intltool supported files. my patch doesn't need to output anything. it transforms scheme syntax into C syntax, so we can actually use gettext to parse the input, including all the features that gettext offers us (comment aggregation, line numbers, multiline strings, etc.) > Not that having correct line numbers wouldn't rock, but you'd still get the > wrong filenames with your approach, so I don't see the benefit. first, this is not just about line numbers, it is enabling *scheme* syntax parsing (for beast, for guile, for anything lisp alike basically). you might want to read my comment #2 again, which describes the exact changes in more detail. second, if any of your parsers are mistaken with regards to line numbers or source file names, thay badly need fixing. there is simply no way to use a development tool productively that doesn't tell where things need fixing (especially with thousands of lines of code to refer to). > Of course, having a regression test would be very welcome, and I am sure you > already got some interesting files in beast which can be added to tests/. yes, i think i even have good examples in the email archives from a previous discussion we had.
GNUCash badly needs this too, at least the correct guile syntax (underscore separated from string by a space).
intltool has switched from the GNOME to the launchpad.net infrastructure nearly three years ago: https://mail.gnome.org/archives/gnome-i18n/2009-April/msg00275.html The intltool product in bugzilla.gnome.org has been deprecated and closed for new bug entry since April 2009. I am now closing all remaining open reports about intltool as NOTGNOME as part of GNOME Bugzilla Housekeeping. Reporter: If the problem that you reported here is still valid in a recent version of intltool we kindly ask you to report it again to https://bugs.launchpad.net/intltool/ so the intltool developers get notified about it.