Re: L20n app workflow?

Robert Kaiser wrote:
> 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).

Yeah.

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

In this case, you can find false positives, for example

<key: "This looks like an entry, <key: \"foo\">, doesn't it?">

I find context sensitive parsers to be much more efficient, sadly, there 
are hardly any out there.

Axel