On 9/8/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > Hi, > > Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit : > > > It would be > > nice to be able to lose the "_()" calls to gettext(). The function > > would look to see if a message catalog was available for the current > > output stream, and if not, do no translation. > > That doesn't sound right to me. > 1. You still need to do automatic extraction of these strings (gettext > has tools for that, which rely on the use of the "_()" function - or any > other dedicated function (*)). > 2. You can't assume that all strings must be i18n'ed. For example if I'm > interfacing with the user via a text-based network protocol which has a > field named "Length", I don't want that "Length" field to be replaced > with the Japanese translation of the word "Length". > > For i18n, "explicit is better than implicit" ;) The beauty of "_()" is > that it's at the same time explicit, easily recognizable, and very short > to type and read (it doesn't clutter the source code). If I dare say, > the "%" operator has the same qualities. > > (*) of course more automatization of what gettext does could be a nice > improvement too!
Here goes something: for applications targeted to the web, where newlines don't matter, the line breaks in _()'ed strings are superfluous. In order to avoid the problem of not being able to "fix" my strings when reindenting the source, and to avoid the need in general to have newlines in the po files, I added an option to pygettext that allows it to flatten the strings in a single line. This does not break the old functionality, just allows you more flexbility in the input source (you can break strings on multiple lines) and the strings in the catalogs are nicer too (no newlines clutter). I submitted a patch on 2005-01-08, nobody has had time to review/integrate it yet. If you're interested, see [ 1098749 ] Single-line option to pygettext.py http://sourceforge.net/tracker/index.php?func=detail&aid=1098749&group_id=5470&atid=305470 cheers, _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
