« Return to Thread: L20n app workflow?
Re: L20n app workflow?
by Axel Hecht
::
Rate this Message:
Robert Kaiser wrote:
> 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.
Merging is needed to reference between application and toolkit strings
back and forth.
>> 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.)
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.
That said, the algorithm to construct the contexts will be very similar
in all language bindings. Things like language selection probably wont,
I think.
>>> 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 think so, too. I just expect that packaging and such would differ
enough for this to be programming-language- and deployment-specific.
>>> 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.
Ah, I saw it mentioned as not supported, but it is just working
differently, as php actually offers an offset argument.
>> 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
Axel
_______________________________________________
dev-i18n mailing list
dev-i18n@...
https://lists.mozilla.org/listinfo/dev-i18n
> 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.
Merging is needed to reference between application and toolkit strings
back and forth.
>> 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.)
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.
That said, the algorithm to construct the contexts will be very similar
in all language bindings. Things like language selection probably wont,
I think.
>>> 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 think so, too. I just expect that packaging and such would differ
enough for this to be programming-language- and deployment-specific.
>>> 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.
Ah, I saw it mentioned as not supported, but it is just working
differently, as php actually offers an offset argument.
>> 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
Axel
_______________________________________________
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 |
