-
Notifications
You must be signed in to change notification settings - Fork 206
SG-12945 + SG-12581 : Added localized param to Shotgun object #208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Pull Request Test Coverage Report for Build 1234
💛 - Coveralls |
This is looking awesome! Thank you, @palisir! For reference, the built docs look like this: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! Loving the docs! Awesome job! Thank you for the new PR and the lovely wrapup!
See comments - mainly around formatting of the docs! No need for further review from me (unless you want to)!
I will add @willis102 as an additional reviewer just to take a quick look at thg python 3 side of things - to ensure that the approach of returning the localized data makes sense in python3 as well as python2.
docs/reference.rst
Outdated
Localization | ||
************ | ||
|
||
Shotgun API offers the ability to return display namnes in user's language. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Shotgun API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does the API know what the user's language is? I think this is worth explaining. Is it based on the user's language preferences in Shotgun? (What happens with script/API users?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
namnes (typo)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: return display namnes in user's language -> return field display names in the current user's language.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the suggestions ! I updated the documentation.
docs/reference.rst
Outdated
* Shotgun.schema_field_read | ||
|
||
Localization is disabled by default. To enable localization, set the ``localized`` property to ``True``. | ||
The property cannot be set at Shotgun class instantiation. When the class is instantiated, the ``localized`` config property is set to ``False``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line 905: i think we can skip this entire line! The example explains it well!
docs/reference.rst
Outdated
Localization is disabled by default. To enable localization, set the ``localized`` property to ``True``. | ||
The property cannot be set at Shotgun class instantiation. When the class is instantiated, the ``localized`` config property is set to ``False``. | ||
|
||
Example for a user whose Language preference is set to Japanese: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: language should have a lower case l
docs/reference.rst
Outdated
Example for a user whose Language preference is set to Japanese: | ||
|
||
.. code-block:: python | ||
:emphasize-lines: 8,19 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
'sg_vendor_groups': { | ||
'mandatory': {'editable': False, 'value': False}, | ||
# the value field (display name) is localized | ||
'name': {'editable': True, 'value': '\xe3\x83\x99\xe3\x83\xb3\xe3\x83\x80\xe3\x83\xbc \xe3\x82\xb0\xe3\x83\xab\xe3\x83\xbc\xe3\x83\x97'}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a UTF-8 encoded string, right? I think we should mention that as part of the docs.
Also, it would be great if @willis102 did a quick CR on this to make sure that this approach still make sense for Python 3!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So yes, this is returning a UTF-8 encoded string in Python 2, and a str in Python 3 (meaning in Python 3 we're not dealing with bytes.) It might be good to mention in the documentation that for Python 2/3 compatibility you can decode the string using shotgun_api3.lib.six.ensure_text()
, ensuring that the Python3 str object is handled properly. I ran your test code in the branch on Python 2 and 3 and it behaved as I would expect.
So, my opinion is that this would be good to mention in the docs but that the current behavior is correct.
docs/reference.rst
Outdated
************ | ||
|
||
Shotgun API offers the ability to return display namnes in user's language. | ||
The server currently returns localized display names for those methods: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest changing this line (and removing the two bullet points below) to "This functionality is currently supported by the methods schema_entity_read
and schema_field_read
."
shotgun_api3/shotgun.py
Outdated
self.config.convert_datetimes_to_utc = convert_datetimes_to_utc | ||
self.config.no_ssl_validation = NO_SSL_VALIDATION | ||
self.config.raw_http_proxy = http_proxy | ||
self.config.localized = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think we need this line - it's already initialized in the constructor for _Config
, right? If we do need it, please explain the reason why with a comment!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct, I removed the line
shotgun_api3/shotgun.py
Outdated
:rtype: dict | ||
.. note:: | ||
The returned display names for this method will be localized when the ``localize`` Shotgun config property is set to ``True``. See :ref:`localization` for more informations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: typo: informations -> information.
shotgun_api3/shotgun.py
Outdated
If you don't specify a ``project_entity``, everything is reported as visible. | ||
.. note:: | ||
The returned display names for this method will be localized when the ``localize`` Shotgun config property is set to ``True``. See :ref:`localization` for more informations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: typo: informations -> information.
(_, _, _, headers) = args | ||
expected_header_value = "auto" | ||
|
||
self.assertEqual("auto", headers.get("locale")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we probably should test whether the schema content coming back from the server is actually localised. Is this easy to do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not hard to do (not sure if we can set the site language from the API, though) but then it would test the server, not the client.
IMO if the requests is made with the right header, the job is done.
Also, the localization on the server is already tested with Cypress on top of Ruby unit tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that makes sense! I was thinking about testing the "receiving end" of the transport, eg. asserting that the received object is a str
and that it's utf-8 encoded etc. Maybe this is one for @willis102 to weigh in on - do you think this test would be meaningful in a py3 cpntext?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, since the encoding/decoding of received objects returned from _call_rpc
is tested elsewhere, so we should be covered by those tests already for this as well. If we do add a test for this, it's important to note that on py3 we will get back a str
object, not bytes, so it will not need to be decoded as in py2. As mentioned above, six.ensure_text()
will ensure that the value is decoded properly on py2 and 3.
'sg_vendor_groups': { | ||
'mandatory': {'editable': False, 'value': False}, | ||
# the value field (display name) is localized | ||
'name': {'editable': True, 'value': '\xe3\x83\x99\xe3\x83\xb3\xe3\x83\x80\xe3\x83\xbc \xe3\x82\xb0\xe3\x83\xab\xe3\x83\xbc\xe3\x83\x97'}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So yes, this is returning a UTF-8 encoded string in Python 2, and a str in Python 3 (meaning in Python 3 we're not dealing with bytes.) It might be good to mention in the documentation that for Python 2/3 compatibility you can decode the string using shotgun_api3.lib.six.ensure_text()
, ensuring that the Python3 str object is handled properly. I ran your test code in the branch on Python 2 and 3 and it behaved as I would expect.
So, my opinion is that this would be good to mention in the docs but that the current behavior is correct.
(_, _, _, headers) = args | ||
expected_header_value = "auto" | ||
|
||
self.assertEqual("auto", headers.get("locale")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, since the encoding/decoding of received objects returned from _call_rpc
is tested elsewhere, so we should be covered by those tests already for this as well. If we do add a test for this, it's important to note that on py3 we will get back a str
object, not bytes, so it will not need to be decoded as in py2. As mentioned above, six.ensure_text()
will ensure that the value is decoded properly on py2 and 3.
The goal of SG-12945 is to expose a new config property named "localized" on the object Shotgun, to give the ability to get localized display names from the server when possible.
The code is tested and documented (according to SG-12581).