C. Scott Ananian wrote:
>On Thu, 23 Aug 2001, Branko [ISO-8859-2] E`ibej wrote:
>
>>>The attached patch replaces getdate.y and getdate.cw with the new
>>>svn_date.c code. Instructions:
>>>
>[...]
>
>>Unfortunately, IMO it not ready for commit yet. [...]
>>
>
>yeah, granted; I just had to do the patch to show y'all that it fits in
>and actually works with the SVN stuff.
>
>Here's my proposal for making it more portable:
> - I like your idea of the apr_strptime function. I also agree that it
> will be very hard to do all the localization stuff in a
> reimplementation of strptime. So apr_strptime should use the native
> strptime if available
>
Absolutely.
>(getting all the localization goodies) or it
> should fall back to its own somewhat simpler implementation of strptime
> otherwise. No localization, but all the basic features will still
> work.
>
Or use native APIs on non-Unix systems. But that can wait, obviously.
>I assume we've got SVN guys in close with the APR developers so
> that I could get a apr_strptime API committed if written?
>
Yes, several of us have commit access to APR. Before you dive into that,
however, I'd recommend gettng familiar with the APR code. The
conventions are different than in SVN.
>> * I wouldn't start using gettext just now. Maybe just use it as a
>> marker. I'd like to take time to review the gettext usage, anyway.
>>
>
> - okay, you should do this ASAP, because I don't like the idea of ripping
> out gettext for no good reason. You've got two choices: catgets or
> gettext. Neither are POSIX, and there are LGPL'ed as well as GPLed
> implementations of both. I don't care which, just choose one.
>
No, you misunderstand. I'm all for using gettext, but right now SVN
isn't localizable at all, so your date parser would be something of an
exception. I don't know that it's worth investing into that now. But
it's your call, obviously.
>> At first glance, it's too simplistic. (For instance, in Slovenian,
>> having only a choice of "%d <whatever> ago" and "%d <whatever>s
>> ago" is not enough.
>>
>
> - That's not a problem for my implementation at all. You can have as
> many phrase entries as you want. Perhaps you could help me out by
> providing all the reasonable Slovenian variants for, let's say, "N
> years ago". Romance languages (with which I am most familiar) are nice
> in that there are very few noun inflections. Slovanian undoubtedly has
> more, but the basic technique should still work: even if Slovanian
> has 99 different noun declensions for the numbers 1-99, we can
> certainly include the forms for "1 year ago" to "9 years ago" which
> should cover the most common cases. I'm not claiming that our parser
> will be able to parse any time concept expressible in the language,
> just the most useful common ones.
>
>>See `info gettext', the bit about mgettext().
>>
>
>I think you meant 'ngettext', which seems to be a GNU-gettext-only
>function.
>
Yah, right. What I meant is, look at the description of what ngettext
can do, and why. Any fixed number of phrases for different inflections
is not enough.
For instance, in Slovenian (which is far from being the most
complicated), you have three forms in this particular case, for 1, 2,
and 3--100 thingumijigs ago; then the're repeated for 101, 102 and
103-200, etc.
My point is, if we /don't/ use ngettext, we'd better make things even
simpler than they are now
> In any case, it's not needed, because the parser is sloppy.
>The current parser allows you to say both:
> "1 years" and "2 year"
>it doesn't care that the nouns don't match. As long as there are a finite
>number of plural forms in Slovenian [there are, right? =) ] we can attempt
>to match them all.
>
Oh, I can guarantee that. For counting, there's only one singular, one
dual(!) and one plural form. The thing is, Slovenian isn't the issue
here (except for me :-), there are many other languages out there, all
of them different.
Maybe having a sloppy parser is actually the best compromise here.
>OK, that's all for now. Off I go to write apr_strptime.
>
Enjoy!
--
Brane �ibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:36 2006