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.


Robert Kaiser
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n