Is there any way to turn off localization when using the REST API with the act_as_user impersonation?
For example, if we call /rest/api/2/issue with the app user, all issue-type names will be in English:
Task, Sub-task, Epic, …
However, if we call /rest/api/2/issue with an impersonated user, the issue-type names will depend on the localization settings of that user:
Opgave, Underopgave, Episk, … (guess the language!)
We need to match names between impersonated and non-impersonated calls. We’d like to avoid making duplicate calls just to match localized names. Is there any way to turn this off or otherwise get the “view” of a user without also getting the localization changed?
If your use-case is to just match issue types, you should match against the issue-type ID instead of the name.
Try calling the API with an Accept-Language header that only allows English, and let me know if that works or not.
@mventnor thanks for the suggestions. We’ve switched from using IDs to names when next-gen was introduced, as issue-types have different IDs but usually the same names when mapping classic to next-gen projects (we allow our customers to clone issues between classic and next-gen projects, or between different next-gen projects). Using issue-type names works very well - if they don’t get translated.
We already tried using the Accept-Language header without success. We also thought about just using all the APIs with the user impersonation - however, we also allow our users to store clone configurations (with issue-type names) and would then again have to ensure those names are mapped to English and back to the user’s language again. We’re aware that this might break if the user renames an issue type, but since this usually happens rarely we’re not too concerned about it.
This also affects more than just issue-type names, e.g. field names or error responses (see ACJIRA-1861). This is especially troubling, as many error cases can only be detected by their error message, and if those get translated we have to match for all possible Jira translations.
@kkercz thanks for the link, I’m now watching this issue hoping it will get resolved soon.