{"action":"created","issue":{"url":"https://api.github.com/repos/translate/translate/issues/3430","repository_url":"https://api.github.com/repos/translate/translate","labels_url":"https://api.github.com/repos/translate/translate/issues/3430/labels{/name}","comments_url":"https://api.github.com/repos/translate/translate/issues/3430/comments","events_url":"https://api.github.com/repos/translate/translate/issues/3430/events","html_url":"https://github.com/translate/translate/pull/3430","id":150376125,"number":3430,"title":"[RFC] multistring: decode bytes if bytes where passed","user":{"login":"julen","id":16768,"avatar_url":"https://avatars.githubusercontent.com/u/16768?v=3","gravatar_id":"","url":"https://api.github.com/users/julen","html_url":"https://github.com/julen","followers_url":"https://api.github.com/users/julen/followers","following_url":"https://api.github.com/users/julen/following{/other_user}","gists_url":"https://api.github.com/users/julen/gists{/gist_id}","starred_url":"https://api.github.com/users/julen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/julen/subscriptions","organizations_url":"https://api.github.com/users/julen/orgs","repos_url":"https://api.github.com/users/julen/repos","events_url":"https://api.github.com/users/julen/events{/privacy}","received_events_url":"https://api.github.com/users/julen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2016-04-22T13:54:51Z","updated_at":"2016-04-23T14:47:45Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/translate/translate/pulls/3430","html_url":"https://github.com/translate/translate/pull/3430","diff_url":"https://github.com/translate/translate/pull/3430.diff","patch_url":"https://github.com/translate/translate/pull/3430.patch"},"body":"We've hit an issue in Pootle which can only be reproduced with TTK master (https://github.com/translate/pootle/issues/4594). The real cause of this is unclear (@phlax mentioned this is originating somewhere in `Store.update()`), and it seems like coercing `multistring`s with non-ASCII data to unicode fails.\r\n\r\nIn that sense, I'm not sure whether `multistring` should accept bytes in its constructor or not, however previously this [used to work via the `autoencode` class](https://github.com/translate/pootle/blob/02c993c59fadde9f495934ce0a34b87d523ad5f1/pootle/apps/pootle_store/fields.py#L59-L79) (note the `UTF-8` argument to the constructor) which is now removed in master.\r\n\r\nI have added a test and a patch for this, which when creating the object would decode bytes from UTF-8 if that was passed. This seems to align with the previous behavior, not sure if we should aim for that though...\r\n\r\n@claudep we'd appreciate to hear your thoughts on this one, TIA :)"},"comment":{"url":"https://api.github.com/repos/translate/translate/issues/comments/213752593","html_url":"https://github.com/translate/translate/pull/3430#issuecomment-213752593","issue_url":"https://api.github.com/repos/translate/translate/issues/3430","id":213752593,"user":{"login":"julen","id":16768,"avatar_url":"https://avatars.githubusercontent.com/u/16768?v=3","gravatar_id":"","url":"https://api.github.com/users/julen","html_url":"https://github.com/julen","followers_url":"https://api.github.com/users/julen/followers","following_url":"https://api.github.com/users/julen/following{/other_user}","gists_url":"https://api.github.com/users/julen/gists{/gist_id}","starred_url":"https://api.github.com/users/julen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/julen/subscriptions","organizations_url":"https://api.github.com/users/julen/orgs","repos_url":"https://api.github.com/users/julen/repos","events_url":"https://api.github.com/users/julen/events{/privacy}","received_events_url":"https://api.github.com/users/julen/received_events","type":"User","site_admin":false},"created_at":"2016-04-23T14:47:45Z","updated_at":"2016-04-23T14:47:45Z","body":"Thanks for the comments, folks. @claudep your comment reinforces my thinking, although as mentioned here we are abruptly breaking backwards compatibility and creating some trouble, hence the middle-ground solution proposed by @phlax is probably the best bet. I have updated the PR to take this into account.\r\n\r\nAs an orthogonal thought, I'm a bit concerned there's no clear path to API deprecation, and we should probably formalize how deprecation/removal is handled in TTK; e.g. unless it becomes absolutely necessary to break backwards compatibility, generally speaking deprecate in version N, remove in version N+1. I believe this would align with common practice out there."}}