[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] automatic apostrophes

From: Robert Millan
Subject: Re: [RFC] automatic apostrophes
Date: Tue, 29 Aug 2006 18:58:06 +0200
User-agent: Mutt/1.5.12-2006-07-14

On Tue, Aug 29, 2006 at 02:08:54PM +0200, Bruno Haible wrote:
> How can such a language-dependent processing be integrated in this simple 
> line:
>    printf (_("%s greets you!"), argv[1]);
> In an abstract point of view, _(...) needs to return a function that can
> analyse its argument, instead of a string. But translators are most often
> not programmers, so the maximum you can provide is a set of language-dependent
> format string directives, which they can choose from.
> A similar thing is done for Farsi: The translator can write "%Id" instead of
> "%d" if she wants 'printf' to use the Arabic digits.
> So what we need is extensibility of 'printf'. In Common Lisp one can write
> an entire function name to be called in a format string. In C, we don't have
> this, but at least on glibc systems, functions can be registered for use in
> 'printf', through 'register_printf_function'.
> If you can write a library of language-dependent string processing functions
> for Catalan, I can do so for French and German, and Paul Eggert for American.
> These libraries can be part of GNU gettext and installed as a shared library
> each. Then we need some code which loads the appropriate shared library at
> program startup and calls 'register_printf_function'. The format string
> that the translator would then write is
>        "%|%1$/en_prefix/|%1$s et saluda!"
> The %|...| is a section that shall disappear on non-glibc systems; inside
> this section, %1$/en_prefix/ looks at its argument and whether it starts
> with a vowel or not. en_prefix is one of the functions from your library.
> Do you like the idea?

I have two concerns with it:

 - What if *printf is not suitable?  E.g. X11 applications.  Will they be
   forced to sprintf it before passing the string to whatever function needs
   to handle them?

 - Can we make the interface more generic?  Idealy, one should be able to pass
   any string without specifiing which kind of "merging" should happen, and let
   the merging function decide itself (it could even be the same function/syntax
   for all languages, by checking which language we're using in runtime).

   For example if I want to print "en %s et saluda!", and I know that "en %s"
   contains enough information to determine wether itself needs to be changed to
   "n'%s", I could tell this function to process "en %s" and then append
   " et saluda!".

I'm not sure if this can be archieved without requiring modifications in the
actual code of the program we're translating.


Robert Millan

My spam trap is address@hidden  Note: this address is only intended for
spam harvesters.  Writing to it will get you added to my black list.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]