Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Support localized fields in API responses
See original GitHub issueIn order to fully switch to API v5, we need to support the new localized fields. Instead of directly getting a value for any localized field, we will always receive an object with at least one key/value (the key is the locale, the value is the localized content).
The API v5 should be used to see those localized fields.
See also: https://github.com/mozilla/addons-server/issues/8794
For QA:
This touches pretty much every part of the site. There should be no observable changes, but we should do a fairly comprehensive regression check.
Issue Analytics
- State:
- Created 5 years ago
- Comments:27 (24 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@willdurand I’m going to work on this as a code quality issue. Do you think we should assume that we’re only getting one locale back from an API request (as we always pass a
langas a query parameter), or is the idea here that we should assume we could be getting multiple locales returned, and we should use the currentlangto look up the value in the returned object? If the latter, what would we do if we don’t find a match for the current lang? I know that should never happen, but if we’re coding to deal with multiple returned langs, we should also code to deal with that scenario.After testing the frontend functionality as a whole, with more focus on localizations, there were no regressions found.
I’m marking this issue as verified fixed on stage.