php-i18n Digest 5 Nov 2010 16:59:53 -0000 Issue 450
Topics (messages 1412 through 1417):
Intl ResourceBundle Class: No Fallback When Using Iteration
1412 by: Joel Sahleen
1413 by: David Zülke
1414 by: Joel Sahleen
1415 by: David Zülke
1416 by: Joel Sahleen
Gettext - finding translations for imported common module
1417 by: Gerry Reno
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
All,
I am working on a large-scale internationalization project that use the intl
extension. I am storing localized strings in ICU resource bundles and accessing
them via the intl ResourceBundle class. Part of my project relies on the
fallback functionality of the ResourceBundle class. I have put all the US
English strings (base language) in the root bundle and created an empty bundle
for en_US as suggested in the ICU guide. That way if any string is missing in
the localized bundles, everything automatically falls back to US English.
Fallback works great if I use the ResourceBundles get method, or if I use array
access (e.g., $bundle->get(‘KEY’) or $bundle[‘KEY’]), but if I try to iterate
over the en_US bundle’s content with foreach, it returns a null result because
the bundle is empty. Is there any way to support fallback when using iteration?
It’s not absolutely necessary for my project, but it seems that if the class is
going to offer iteration support, that functionality should also support the
fallback functionality.
Thanks for the help.
Joel Sahleen
Software Engineer
Adobe Systems
--- End Message ---
--- Begin Message ---
That seems to be a bug.
Among other things, resourcebundle_iterator_read calls
resourcebundle_extract_value instead of resourcebundle_array_get (which handles
fallbacks via resourcebundle_array_fetch).
I'm not sure if the fix is that simple though, as that only fixes getting of
values, but the iterated range probably still doesn't include the fallback
values. What would the expected behavior be for iterators? Should it iterate
over all contents, including fallbacks? You sent another message to the list
earlier which appears to be describing a similar, but different problem where
values are null when iterating?
- David
On 16.08.2010, at 23:05, Joel Sahleen wrote:
> All,
>
> I am working on a large-scale internationalization project that use the intl
> extension. I am storing localized strings in ICU resource bundles and
> accessing them via the intl ResourceBundle class. Part of my project relies
> on the fallback functionality of the ResourceBundle class. I have put all the
> US English strings (base language) in the root bundle and created an empty
> bundle for en_US as suggested in the ICU guide. That way if any string is
> missing in the localized bundles, everything automatically falls back to US
> English.
>
> Fallback works great if I use the ResourceBundles get method, or if I use
> array access (e.g., $bundle->get(‘KEY’) or $bundle[‘KEY’]), but if I try to
> iterate over the en_US bundle’s content with foreach, it returns a null
> result because the bundle is empty. Is there any way to support fallback when
> using iteration? It’s not absolutely necessary for my project, but it seems
> that if the class is going to offer iteration support, that functionality
> should also support the fallback functionality.
>
> Thanks for the help.
>
> Joel Sahleen
> Software Engineer
> Adobe Systems
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
--- Begin Message ---
Sorry about the double message. I was using Nabble and it didn't seem to
post correctly. Values are null when iterating in the sense that if you have
an empty bundle, there is no fallback.
As I said this isn't immediately necessary for my project, but the expected
behavior would seem to be that iteration should work over all contents,
including fallbacks. I understand why that might be difficult to implement,
however. At very least a note should be added explaining that iteration will
not work with fallback. I'm afraid I will have developers trying to do that
if they just go by the documentation.
Joel
On 8/17/10 5:02 AM, "David Zülke" <[email protected]> wrote:
> That seems to be a bug.
>
> Among other things, resourcebundle_iterator_read calls
> resourcebundle_extract_value instead of resourcebundle_array_get (which
> handles fallbacks via resourcebundle_array_fetch).
>
> I'm not sure if the fix is that simple though, as that only fixes getting of
> values, but the iterated range probably still doesn't include the fallback
> values. What would the expected behavior be for iterators? Should it iterate
> over all contents, including fallbacks? You sent another message to the list
> earlier which appears to be describing a similar, but different problem where
> values are null when iterating?
>
> - David
>
>
>
> On 16.08.2010, at 23:05, Joel Sahleen wrote:
>
>> All,
>>
>> I am working on a large-scale internationalization project that use the intl
>> extension. I am storing localized strings in ICU resource bundles and
>> accessing them via the intl ResourceBundle class. Part of my project relies
>> on the fallback functionality of the ResourceBundle class. I have put all the
>> US English strings (base language) in the root bundle and created an empty
>> bundle for en_US as suggested in the ICU guide. That way if any string is
>> missing in the localized bundles, everything automatically falls back to US
>> English.
>>
>> Fallback works great if I use the ResourceBundles get method, or if I use
>> array access (e.g., $bundle->get(ŒKEY¹) or $bundle[ŒKEY¹]), but if I try to
>> iterate over the en_US bundle¹s content with foreach, it returns a null
>> result because the bundle is empty. Is there any way to support fallback when
>> using iteration? It¹s not absolutely necessary for my project, but it seems
>> that if the class is going to offer iteration support, that functionality
>> should also support the fallback functionality.
>>
>> Thanks for the help.
>>
>> Joel Sahleen
>> Software Engineer
>> Adobe Systems
>
--- End Message ---
--- Begin Message ---
That still doesn't explain the problem clearly.
You said you have a root file, and an empty en_US extending from it?
If you now open the en_US bundle and iterate over it, does the iterator
a) not return anything at all, i.e. because the collection is empty, or
b) iterate over the correct number of entries (with correct keys maybe?), but
just not return the corresponding values?
b) would be a relatively trivial fix, a) is a bit more work
- David
On 17.08.2010, at 13:13, Joel Sahleen wrote:
> Sorry about the double message. I was using Nabble and it didn't seem to
> post correctly. Values are null when iterating in the sense that if you have
> an empty bundle, there is no fallback.
>
> As I said this isn't immediately necessary for my project, but the expected
> behavior would seem to be that iteration should work over all contents,
> including fallbacks. I understand why that might be difficult to implement,
> however. At very least a note should be added explaining that iteration will
> not work with fallback. I'm afraid I will have developers trying to do that
> if they just go by the documentation.
>
> Joel
>
>
> On 8/17/10 5:02 AM, "David Zülke" <[email protected]> wrote:
>
>> That seems to be a bug.
>>
>> Among other things, resourcebundle_iterator_read calls
>> resourcebundle_extract_value instead of resourcebundle_array_get (which
>> handles fallbacks via resourcebundle_array_fetch).
>>
>> I'm not sure if the fix is that simple though, as that only fixes getting of
>> values, but the iterated range probably still doesn't include the fallback
>> values. What would the expected behavior be for iterators? Should it iterate
>> over all contents, including fallbacks? You sent another message to the list
>> earlier which appears to be describing a similar, but different problem where
>> values are null when iterating?
>>
>> - David
>>
>>
>>
>> On 16.08.2010, at 23:05, Joel Sahleen wrote:
>>
>>> All,
>>>
>>> I am working on a large-scale internationalization project that use the intl
>>> extension. I am storing localized strings in ICU resource bundles and
>>> accessing them via the intl ResourceBundle class. Part of my project relies
>>> on the fallback functionality of the ResourceBundle class. I have put all
>>> the
>>> US English strings (base language) in the root bundle and created an empty
>>> bundle for en_US as suggested in the ICU guide. That way if any string is
>>> missing in the localized bundles, everything automatically falls back to US
>>> English.
>>>
>>> Fallback works great if I use the ResourceBundles get method, or if I use
>>> array access (e.g., $bundle->get(ŒKEY¹) or $bundle[ŒKEY¹]), but if I try to
>>> iterate over the en_US bundle¹s content with foreach, it returns a null
>>> result because the bundle is empty. Is there any way to support fallback
>>> when
>>> using iteration? It¹s not absolutely necessary for my project, but it seems
>>> that if the class is going to offer iteration support, that functionality
>>> should also support the fallback functionality.
>>>
>>> Thanks for the help.
>>>
>>> Joel Sahleen
>>> Software Engineer
>>> Adobe Systems
>>
>
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
--- Begin Message ---
Sorry for the confusion.
If I open the en_US bundle, the iterator returns nothing at all because the
collection is empty.
On 8/17/10 5:17 AM, "David Zülke" <[email protected]> wrote:
> That still doesn't explain the problem clearly.
>
> You said you have a root file, and an empty en_US extending from it?
>
> If you now open the en_US bundle and iterate over it, does the iterator
> a) not return anything at all, i.e. because the collection is empty, or
> b) iterate over the correct number of entries (with correct keys maybe?), but
> just not return the corresponding values?
>
> b) would be a relatively trivial fix, a) is a bit more work
>
> - David
>
>
>
> On 17.08.2010, at 13:13, Joel Sahleen wrote:
>
>> Sorry about the double message. I was using Nabble and it didn't seem to
>> post correctly. Values are null when iterating in the sense that if you have
>> an empty bundle, there is no fallback.
>>
>> As I said this isn't immediately necessary for my project, but the expected
>> behavior would seem to be that iteration should work over all contents,
>> including fallbacks. I understand why that might be difficult to implement,
>> however. At very least a note should be added explaining that iteration will
>> not work with fallback. I'm afraid I will have developers trying to do that
>> if they just go by the documentation.
>>
>> Joel
>>
>>
>> On 8/17/10 5:02 AM, "David Zülke" <[email protected]> wrote:
>>
>>> That seems to be a bug.
>>>
>>> Among other things, resourcebundle_iterator_read calls
>>> resourcebundle_extract_value instead of resourcebundle_array_get (which
>>> handles fallbacks via resourcebundle_array_fetch).
>>>
>>> I'm not sure if the fix is that simple though, as that only fixes getting of
>>> values, but the iterated range probably still doesn't include the fallback
>>> values. What would the expected behavior be for iterators? Should it iterate
>>> over all contents, including fallbacks? You sent another message to the list
>>> earlier which appears to be describing a similar, but different problem
>>> where
>>> values are null when iterating?
>>>
>>> - David
>>>
>>>
>>>
>>> On 16.08.2010, at 23:05, Joel Sahleen wrote:
>>>
>>>> All,
>>>>
>>>> I am working on a large-scale internationalization project that use the
>>>> intl
>>>> extension. I am storing localized strings in ICU resource bundles and
>>>> accessing them via the intl ResourceBundle class. Part of my project relies
>>>> on the fallback functionality of the ResourceBundle class. I have put all
>>>> the
>>>> US English strings (base language) in the root bundle and created an empty
>>>> bundle for en_US as suggested in the ICU guide. That way if any string is
>>>> missing in the localized bundles, everything automatically falls back to US
>>>> English.
>>>>
>>>> Fallback works great if I use the ResourceBundles get method, or if I use
>>>> array access (e.g., $bundle->get(ŒKEY¹) or $bundle[ŒKEY¹]), but if I try to
>>>> iterate over the en_US bundle¹s content with foreach, it returns a null
>>>> result because the bundle is empty. Is there any way to support fallback
>>>> when
>>>> using iteration? It¹s not absolutely necessary for my project, but it seems
>>>> that if the class is going to offer iteration support, that functionality
>>>> should also support the fallback functionality.
>>>>
>>>> Thanks for the help.
>>>>
>>>> Joel Sahleen
>>>> Software Engineer
>>>> Adobe Systems
>>>
>>
>>
>> --
>> PHP Unicode & I18N Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
--- End Message ---
--- Begin Message ---
I am using PHP 5.2.4 and gettext.
I have a common module that I import (require) into other modules.
But when I do this pages (at a different level in site tree) do not show
the translations for this module.
/siteroot
/siteroot/lib/common.php
/siteroot/lib/locale/[LANG]/LC_MESSAGES/message.po #COMMON MODULE
TRANSLATIONS ARE IN HERE
/siteroot/index.php #require("lib/common.php") #NO
COMMON MODULE TRANSLATION OCCURS
/siteroot/locale/[LANG]/LC_MESSAGES/message.po
/siteroot/page2/index.php #require("../lib/common.php") #NO COMMON
MODULE TRANSLATION OCCURS
/siteroot/page2/locale/[LANG]/LC_MESSAGES/message.po
Right now all the regular translations work fine but the imported module
is not translated even though I have the translations for it under the
/siteroot/lib directory.
If I put the common module translation into each po file under each
/siteroot/pageN directory then the common module translations work but
this requires tons of duplication.
Is there a way to bind an alternate root or domain so that gettext can
find both the local translations and the library translations for the
imported common modules?
--- End Message ---
