Travis Vitek wrote:
Martin Sebor wrote:
But we do need to come up with a sound specification of the query syntax
before implementing any more code.
Okay, the proposed query syntax grammar essentially the same as that being
used for the value in xfail.txt. So we have
is a shell globbing
Martin Sebor wrote:
>
> But we do need to come up with a sound specification of the query syntax
> before implementing any more code.
>
Okay, the proposed query syntax grammar essentially the same as that being
used for the value in xfail.txt. So we have
is a shell globbing pattern in th
Travis Vitek wrote:
[...]
I think it might be simpler to keep things abstract but given my
specification above a simple query string would look like this:
"en_US.*1\n"
"zh_*.UTF-8 2\n"
"zh_*.UTF-8 3\n"
"zh_*.UTF-8 4\n"
for the equivalent of:
locale == "en_US.*"&& MB_C
Travis, I don't think we've been wasting time. But we do need to come
up with a sound specification of the query syntax before implementing
any more code. Examples are helpful, but they are not a substitute for
a precise grammar and a description of the effects. I think it's great
to put together
>
>
>
> Martin Sebor wrote:
>
> Travis Vitek wrote:
>>
>>
>>> From: Apache Wiki [mailto:[EMAIL PROTECTED]
>>>
>>> The new
>>> interface will need to make it easy to specify such a set of
>>> locales without explicitly naming them, and it will need to
>>> retrieve such locales without ret
Travis Vitek wrote:
From: Apache Wiki [mailto:[EMAIL PROTECTED]
The new
interface will need to make it easy to specify such a set of
locales without explicitly naming them, and it will need to
retrieve such locales without returning duplicates.
As mentioned before I don't know a good wa
>From: Apache Wiki [mailto:[EMAIL PROTECTED]
>
>The new
>interface will need to make it easy to specify such a set of
>locales without explicitly naming them, and it will need to
>retrieve such locales without returning duplicates.
>
As mentioned before I don't know a good way to avoid dupli
