Re: [openstack-dev] [oslo] Question on oslo_i18n._message

2015-08-11 Thread Doug Hellmann
Excerpts from Okuma, Wayne's message of 2015-08-11 02:49:28 +:
 
 -Original Message-
 From: Doug Hellmann [mailto:d...@doughellmann.com] 
 Sent: Monday, August 10, 2015 4:00 PM
 To: openstack-dev
 Subject: Re: [openstack-dev] [oslo] Question on oslo_i18n._message
 
 Excerpts from Okuma, Wayne's message of 2015-08-10 21:22:09 +:
  Hello All,
  
  I have a question on the usage of oslo_i18n._message and hope to get an 
  answer.
  
  Some background first:
  I'm working on a portion of Glance - the Glance Metadata Definitions (i.e., 
  metadefs) section.
  We have about ~20 .JSON files which hold data. The .JSON files get loaded 
  into the Glance.metadef_xxx related tables which in turn gets displayed in 
  Horizon via the glance REST API code.
  There are some fields in the .JSON files which need to be internationalized.
  I have a program which produces glance-json.pot files for the JSON files.
  
  In Horizon, when they are viewing the data, the end-user may change the 
  language they wish to see by going into the profile section (upper right 
  hand corner of Horizon) and selecting the language. So,  I need a more 
  dynamic version of i18n than just the version of i18n that gets started up 
  when the Glance service is started (i.e., based on GLANCE_LOCALEDIR and 
  LANGUAGE, LANG, etc., settings).
 
 The API layer can also set a language based on the browser settings. Are the 
 JSON files being served by the glance API? Or are they in some other way 
 coming through from glance?
 
 WO: The JSON data is being served by the REST API as far as I know. The 
 current API doesn't support being passed a locale flag yet though.

I think the idea is to use the existing HTTP headers for describing the
locale, rather than an explicit parameter to the API endpoint.

  
  This seems to work:
  
  import oslo_i18n
  
  # Assumes GLANCE_JSON_LOCALEDIR has been set appropriately.
  def translate(message, locale=None):
  obj = oslo_i18n._message.Message(message, domain='glance-json')
  return oslo_i18n.translate(obj, locale) ...
  # then in code...
  def _format_namespace_from_db(self, namespace_obj, locale=None):
  ...
  display_name=translate(namespace_obj['display_name'], locale),
  
  The returned display_name will have the correct version based on the locale 
  passed in.
  
  But, is this correct usage of oslo_i18n._message()?
  Or is it to remain hidden since it is not part of oslo_i18n.__init__py?
  If it is to remain hidden, then, what would be the better way of getting a 
  dynamic translation based on some arbitrary locale that is passed in.
  
  If you don't know the answer, but, know someone that might - please pass on 
  their name(s) and I can try to contact them directly.
  
  Thanks and Regards,
  Wayne Okuma
 
 As you surmise, the _message module is marked private (note the _ prefix 
 on the name), so you shouldn't use it directly. The fact that Message objects 
 exists is an implementation detail of the lazy translation machinery, and 
 isn't meant to be something that applications rely on.
 
 You could use oslo_i18n.TranslatorFactory to get a function to wrap your 
 strings instead [1].  The primary attribute should be what you want. 
 Passing the return value to translate() would then give you the translated 
 value.
 
 Something like:
 
   factory = oslo_i18n.TranslatorFactory('glance-json')
   trans = factory.primary
 
   def translate(message, locale=None):
   return oslo_i18n.translate(trans(message), locale)
 
 This ought to work whether lazy translation is enabled or not, as long as the 
 catalog files are installed properly.
 
 Doug
 
 WO: The above works for me...Thanks. I'm curious if there will be a version 
 in which a global set of already opened catalogues will be kept for the 
 sake of efficiency?

You can hold onto the TranslatorFactory instance to accomplish that, but
we don't have any plans to hide something like that inside the library.

Doug

 
 [1] 
 http://docs.openstack.org/developer/oslo.i18n/api.html#oslo_i18n.TranslatorFactory
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [oslo] Question on oslo_i18n._message

2015-08-10 Thread Okuma, Wayne
Hello All,

I have a question on the usage of oslo_i18n._message and hope to get an answer.

Some background first:
I'm working on a portion of Glance - the Glance Metadata Definitions (i.e., 
metadefs) section.
We have about ~20 .JSON files which hold data. The .JSON files get loaded into 
the Glance.metadef_xxx related tables which in turn gets displayed in Horizon 
via the glance REST API code.
There are some fields in the .JSON files which need to be internationalized.
I have a program which produces glance-json.pot files for the JSON files.

In Horizon, when they are viewing the data, the end-user may change the 
language they wish to see by going into the profile section (upper right hand 
corner of Horizon) and selecting the language. So,  I need a more dynamic 
version of i18n than just the version of i18n that gets started up when the 
Glance service is started (i.e., based on GLANCE_LOCALEDIR and LANGUAGE, LANG, 
etc., settings).

This seems to work:

import oslo_i18n

# Assumes GLANCE_JSON_LOCALEDIR has been set appropriately.
def translate(message, locale=None):
obj = oslo_i18n._message.Message(message, domain='glance-json')
return oslo_i18n.translate(obj, locale)
...
# then in code...
def _format_namespace_from_db(self, namespace_obj, locale=None):
...
display_name=translate(namespace_obj['display_name'], locale),

The returned display_name will have the correct version based on the locale 
passed in.

But, is this correct usage of oslo_i18n._message()?
Or is it to remain hidden since it is not part of oslo_i18n.__init__py?
If it is to remain hidden, then, what would be the better way of getting a 
dynamic translation based on some arbitrary locale that is passed in.

If you don't know the answer, but, know someone that might - please pass on 
their name(s) and I can try to contact them directly.

Thanks and Regards,
Wayne Okuma

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Question on oslo_i18n._message

2015-08-10 Thread Doug Hellmann
Excerpts from Okuma, Wayne's message of 2015-08-10 21:22:09 +:
 Hello All,
 
 I have a question on the usage of oslo_i18n._message and hope to get an 
 answer.
 
 Some background first:
 I'm working on a portion of Glance - the Glance Metadata Definitions (i.e., 
 metadefs) section.
 We have about ~20 .JSON files which hold data. The .JSON files get loaded 
 into the Glance.metadef_xxx related tables which in turn gets displayed in 
 Horizon via the glance REST API code.
 There are some fields in the .JSON files which need to be internationalized.
 I have a program which produces glance-json.pot files for the JSON files.
 
 In Horizon, when they are viewing the data, the end-user may change the 
 language they wish to see by going into the profile section (upper right hand 
 corner of Horizon) and selecting the language. So,  I need a more dynamic 
 version of i18n than just the version of i18n that gets started up when the 
 Glance service is started (i.e., based on GLANCE_LOCALEDIR and LANGUAGE, 
 LANG, etc., settings).

The API layer can also set a language based on the browser settings. Are
the JSON files being served by the glance API? Or are they in some other
way coming through from glance?

 
 This seems to work:
 
 import oslo_i18n
 
 # Assumes GLANCE_JSON_LOCALEDIR has been set appropriately.
 def translate(message, locale=None):
 obj = oslo_i18n._message.Message(message, domain='glance-json')
 return oslo_i18n.translate(obj, locale)
 ...
 # then in code...
 def _format_namespace_from_db(self, namespace_obj, locale=None):
 ...
 display_name=translate(namespace_obj['display_name'], locale),
 
 The returned display_name will have the correct version based on the locale 
 passed in.
 
 But, is this correct usage of oslo_i18n._message()?
 Or is it to remain hidden since it is not part of oslo_i18n.__init__py?
 If it is to remain hidden, then, what would be the better way of getting a 
 dynamic translation based on some arbitrary locale that is passed in.
 
 If you don't know the answer, but, know someone that might - please pass on 
 their name(s) and I can try to contact them directly.
 
 Thanks and Regards,
 Wayne Okuma

As you surmise, the _message module is marked private (note the
_ prefix on the name), so you shouldn't use it directly. The fact that
Message objects exists is an implementation detail of the lazy
translation machinery, and isn't meant to be something that applications
rely on.

You could use oslo_i18n.TranslatorFactory to get a function to wrap
your strings instead [1].  The primary attribute should be what
you want. Passing the return value to translate() would then give
you the translated value.

Something like:

  factory = oslo_i18n.TranslatorFactory('glance-json')
  trans = factory.primary

  def translate(message, locale=None):
  return oslo_i18n.translate(trans(message), locale)

This ought to work whether lazy translation is enabled or not, as long
as the catalog files are installed properly.

Doug

[1] 
http://docs.openstack.org/developer/oslo.i18n/api.html#oslo_i18n.TranslatorFactory

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Question on oslo_i18n._message

2015-08-10 Thread Okuma, Wayne


-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Monday, August 10, 2015 4:00 PM
To: openstack-dev
Subject: Re: [openstack-dev] [oslo] Question on oslo_i18n._message

Excerpts from Okuma, Wayne's message of 2015-08-10 21:22:09 +:
 Hello All,
 
 I have a question on the usage of oslo_i18n._message and hope to get an 
 answer.
 
 Some background first:
 I'm working on a portion of Glance - the Glance Metadata Definitions (i.e., 
 metadefs) section.
 We have about ~20 .JSON files which hold data. The .JSON files get loaded 
 into the Glance.metadef_xxx related tables which in turn gets displayed in 
 Horizon via the glance REST API code.
 There are some fields in the .JSON files which need to be internationalized.
 I have a program which produces glance-json.pot files for the JSON files.
 
 In Horizon, when they are viewing the data, the end-user may change the 
 language they wish to see by going into the profile section (upper right hand 
 corner of Horizon) and selecting the language. So,  I need a more dynamic 
 version of i18n than just the version of i18n that gets started up when the 
 Glance service is started (i.e., based on GLANCE_LOCALEDIR and LANGUAGE, 
 LANG, etc., settings).

The API layer can also set a language based on the browser settings. Are the 
JSON files being served by the glance API? Or are they in some other way coming 
through from glance?

WO: The JSON data is being served by the REST API as far as I know. The current 
API doesn't support being passed a locale flag yet though.
 
 This seems to work:
 
 import oslo_i18n
 
 # Assumes GLANCE_JSON_LOCALEDIR has been set appropriately.
 def translate(message, locale=None):
 obj = oslo_i18n._message.Message(message, domain='glance-json')
 return oslo_i18n.translate(obj, locale) ...
 # then in code...
 def _format_namespace_from_db(self, namespace_obj, locale=None):
 ...
 display_name=translate(namespace_obj['display_name'], locale),
 
 The returned display_name will have the correct version based on the locale 
 passed in.
 
 But, is this correct usage of oslo_i18n._message()?
 Or is it to remain hidden since it is not part of oslo_i18n.__init__py?
 If it is to remain hidden, then, what would be the better way of getting a 
 dynamic translation based on some arbitrary locale that is passed in.
 
 If you don't know the answer, but, know someone that might - please pass on 
 their name(s) and I can try to contact them directly.
 
 Thanks and Regards,
 Wayne Okuma

As you surmise, the _message module is marked private (note the _ prefix on 
the name), so you shouldn't use it directly. The fact that Message objects 
exists is an implementation detail of the lazy translation machinery, and isn't 
meant to be something that applications rely on.

You could use oslo_i18n.TranslatorFactory to get a function to wrap your 
strings instead [1].  The primary attribute should be what you want. Passing 
the return value to translate() would then give you the translated value.

Something like:

  factory = oslo_i18n.TranslatorFactory('glance-json')
  trans = factory.primary

  def translate(message, locale=None):
  return oslo_i18n.translate(trans(message), locale)

This ought to work whether lazy translation is enabled or not, as long as the 
catalog files are installed properly.

Doug

WO: The above works for me...Thanks. I'm curious if there will be a version in 
which a global set of already opened catalogues will be kept for the sake of 
efficiency?

[1] 
http://docs.openstack.org/developer/oslo.i18n/api.html#oslo_i18n.TranslatorFactory

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev