bug-gnu-utils
[Top][All Lists]
Advanced

[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: Wed, 27 Sep 2006 20:16:47 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Sorry, I've been a bit busy... :(

Where are we on this, how should this be implemented exactly?  I'm happy
with anything that works; earlier I made some suggestions but these details
aren't really important for me.  If you tell me what you want, I'm happy to try
providing a patch.

Btw, I found a similar situation that IMHO should also be handled.  String
is:  "No hi ha una entrada de manual de %s" (there is no manpage for %s).  When
Catalan apostrophe rules apply, it should be "... d'%s" instead.

On Tue, Aug 29, 2006 at 09:13:04PM +0200, Robert Millan wrote:
> On Tue, Aug 29, 2006 at 08:33:40PM +0200, Bruno Haible wrote:
> > Robert Millan wrote:
> > >  - 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?
> > 
> > Yes. sprintf or asprintf is the standard function for merging strings or
> > numbers into strings. X11 applications use it.
> 
> Oh, right.. :)
> 
> > >  - 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).
> > 
> > Basically, you want to define localized_*printf functions for every 
> > language?
> > Given that sprintf is already at least ca. 25 KB of code without any
> > locale dependent extension, how can this be made manageable?
> 
> Ok, if size is a problem, I suppose we can get the program to select the code
> for the current language in runtime?
> 
> Though, the important for me is the former part, about having the same routine
> to handle all string "merging" for a given language.  For Catalan it is
> important because there are lots of variations but they follow the same 
> pattern,
> so the same code can be used to handle all them (the code for Catalan won't be
> trivial; there are a pair of complicated exceptions to the "starts with 
> vowel?"
> rule).
> 
> > >    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!".
> > 
> > We need a working prototype before deciding whether such "magic processing"
> > is the good approach, or whether more explicit directives are better for
> > locale-dependent processing.
> 
> That's why I think it should be less explicit, and more generic.  If the 
> special
> syntax we add to printf handles simple string replacements, then it'll scale 
> to
> anything we want to do with it.  We know that a string replacement is always
> usable, because more context can be added to the string untill there's enough
> to determine wether it needs to be changed, and how.
> 
> For example, in Catalan the string "en %s" is enough to tell if itself needs
> modification, but in English you might want to perform sophisticated checks on
> the context to determine what "Ajax" means [1].
> 
> [1] Like Paul, I'm just using this as an example.  I don't really think 
> someone
>     will try that!
> 
> -- 
> 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.

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