-
Notifications
You must be signed in to change notification settings - Fork 120
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
Not possible to submit a translation containing the UTF-8 characters → and ↵ #648
Comments
A bit surprised that it gets interpreted as a suggestion, it should only be a visual hint so the user enters a real line break (adding a tab isn't possible IIRC). |
I didn't word this properly. I don't see it as a suggestion but the code obviously allows for such an interpretation which I don't consider necessary. |
@ocean90 you can add a tab, but it's a bit convoluted, use a text editor, create a tab then copy/paste it in to the translation field. @akirk I agree, the code allows for those UTF8 characters to be used to represent an actual tab/CR. I think we should simply remove the We'd have to fix the "copy from original" code as well though as it pulls the UTF characters in to the translation field at the moment. The other option would be to put a note somewhere (maybe only when the original has them) that you need to use the html entities for the tab/CR characters (though that assumes that the outputted translation is going to be used for the web). |
It seems the 'rightwards arrow' → cannot be added into a translation. How about changing the '→' to '⟶' during the "copy from original" as a workaround? |
See my previous comment, we should just fix the core issue and not try and replace the characters in the first place. I have 90% or a PR done for it, should have it posted later today. |
This is caused by
fix_translation()
in https://github.com/GlotPress/GlotPress-WP/blob/master/gp-includes/things/translation.php#L267 and due to the UI suggesting to use → for tabs and ↵ for line-breaks.These fixes of translations are also applied if the translation is imported, i.e. no UI involved, hence causing unexpected results.
Possible solution: only apply the fixes if the original output contains these characters.
A common workaround applied is to use
→
instead of the UTF-8 character.The text was updated successfully, but these errors were encountered: