Re: L20n app workflow?

> Axel Hecht schrieb:
>> Merging is needed to reference between application and toolkit strings
>> back and forth.
>
> I would have suspected that a namespaced solution would work just as
> well there, esp. when a default namespace (context, "file" or whatevery
> you call it) is set.
>
>>  From my own state of mind, language mappings will be most elegant in
>> loosely typed OO languages as JavaScript. Strongly typed languages
>> will have face some challenges for programmatic parameters. Non-OO
>> languages will likely suck, as any attempt to do objects in those
>> language will.
>
> I think we agree on that. JS and PHP5 will probably look quite nice ;-)
>
>> That said, the algorithm to construct the contexts will be very
>> similar in all language bindings. Things like language selection
>> probably wont, I think.
>
> Hmm, I'd guess it should be somehow consistent though.
>
> Would be nice to see some basic code in multiple programming languages
> to find out how well this all works out. For the first tests, it would
> probably be enough if they understood "simple" L20n objects, dealing
> with the more complicated structures can then be implemented on top of
> that (esp. as it's bascially all just in the library layer).

>>> I see \G mentioned in the preg_* (PCRE-based regex) module
>>> documentation, and from what I read, preg-* is preferred over ereg_*
>>> (POSIX-extended regex) due to being binary-safe, faster and more
>>> powerful.
>>
>> Ah, I saw it mentioned as not supported, but it is just working
>> differently, as php actually offers an offset argument.
>
> Yes, true. I very much like preg_match_all() actually for cases where
> you need to find recurring patterns (as I expect we'll need). This often
> is a good option in places where you else would go with \G-constructs, I
> guess.