« Return to Thread: L20n app workflow?
Re: L20n app workflow?
by Robert Kaiser
::
Rate this Message:
Axel Hecht schrieb:
> The workflow is basically 1), mostly because we need to support that
> anyway. The stringbundle workflow is similar, just that you can provide
> more than one file.
Actually, for me, the gettext solution sounds like some mid-way between
our two variants - though it doesn't merge namespaces like XUL currently
does. I'm not sure if that merging is good to do, desired or even needed
though.
> I'm calling the sets of lol files that are packed up "contexts", in
> which entities are resolved. Those contexts include both programmatic
> parameters and fallback. How those ocntexts are set up depends on the
> language mapping.
Hmm, I wonder if there should be some specified, cross-language-portable
way of accessing lol files/contexts, though, so that you can use them in
basically the same style from C/C++, PHP, JS, Java or whatever.
(Though I'd prefer an object-based solution where OO is supported well
enough, i.e. C++, PHP5, JS, etc.)
>> Additionally, how is L20n supposed to find its files for a specific
>> language as well as the files for fallbacks?
>
> That's not clearly specified yet. In the case of, say, multiple
> spanishs, it's not really clear who's falling back to what, and it might
> depend on the "module" in whatever sense.
>
> This is, again, part of the language binding. It might make sense to
> support some kind of specification of fallback in the lol file itself,
> though I'm not sure that's the right modularity.
I think we should try to have the possibility to use the same set of lol
files from different languages, so some generic specification of finding
files and doing fallback sounds like a good idea.
>> I'd really like to do some crude testing implementation for PHP just
>> to see if L20n is really as good as I imagine it currently. From what
>> I know currently, the L20n concepts also make dev work much easier for
>> me in PHP (not needing to implement plural selectors in the code
>> itself in many places, leave that up to the localization layer, for
>> example - and of course getting rid of long original strings mixed
>> into the code).
>> Would be cool to be able to test some of that ;-)
>
> We should get interested people together, we should poke at least Wil
> Clouser and Adrian Kalla.
That would be cool. I'm sure many web-based tools would profit from a
good PHP impl (even better and faster would probably be some native
support inside PHP but such stuff usually takes longer).
> It seems that php doesn't support /y of js re (new in 1.9) nor \G,
> implementing the parser performantly might not be able to use regular
> expressions :-/.
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.
> You can see, I'm pretty interested in getting a php-based impl, as that
> should really get the most exposure per impl.
I think so as well. And it would/will probably be a good proof of the
concepts.
Robert Kaiser
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
> The workflow is basically 1), mostly because we need to support that
> anyway. The stringbundle workflow is similar, just that you can provide
> more than one file.
Actually, for me, the gettext solution sounds like some mid-way between
our two variants - though it doesn't merge namespaces like XUL currently
does. I'm not sure if that merging is good to do, desired or even needed
though.
> I'm calling the sets of lol files that are packed up "contexts", in
> which entities are resolved. Those contexts include both programmatic
> parameters and fallback. How those ocntexts are set up depends on the
> language mapping.
Hmm, I wonder if there should be some specified, cross-language-portable
way of accessing lol files/contexts, though, so that you can use them in
basically the same style from C/C++, PHP, JS, Java or whatever.
(Though I'd prefer an object-based solution where OO is supported well
enough, i.e. C++, PHP5, JS, etc.)
>> Additionally, how is L20n supposed to find its files for a specific
>> language as well as the files for fallbacks?
>
> That's not clearly specified yet. In the case of, say, multiple
> spanishs, it's not really clear who's falling back to what, and it might
> depend on the "module" in whatever sense.
>
> This is, again, part of the language binding. It might make sense to
> support some kind of specification of fallback in the lol file itself,
> though I'm not sure that's the right modularity.
I think we should try to have the possibility to use the same set of lol
files from different languages, so some generic specification of finding
files and doing fallback sounds like a good idea.
>> I'd really like to do some crude testing implementation for PHP just
>> to see if L20n is really as good as I imagine it currently. From what
>> I know currently, the L20n concepts also make dev work much easier for
>> me in PHP (not needing to implement plural selectors in the code
>> itself in many places, leave that up to the localization layer, for
>> example - and of course getting rid of long original strings mixed
>> into the code).
>> Would be cool to be able to test some of that ;-)
>
> We should get interested people together, we should poke at least Wil
> Clouser and Adrian Kalla.
That would be cool. I'm sure many web-based tools would profit from a
good PHP impl (even better and faster would probably be some native
support inside PHP but such stuff usually takes longer).
> It seems that php doesn't support /y of js re (new in 1.9) nor \G,
> implementing the parser performantly might not be able to use regular
> expressions :-/.
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.
> You can see, I'm pretty interested in getting a php-based impl, as that
> should really get the most exposure per impl.
I think so as well. And it would/will probably be a good proof of the
concepts.
Robert Kaiser
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
« Return to Thread: L20n app workflow?
| Free embeddable forum powered by Nabble | Forum Help |
