Special Character conflict with Transifex keyboards

I am trying to add a language special character, but when using the shortcut to add the special character (like “é”), it will copy a variable from the translation, or present another action.

In TX editor preferences, you can disable shortcuts to avoid your keyboard shortcut to conflicts with Transifex shortcuts.

Another option is to pop up the fallback/accessibility editor, which is a simple textarea without all the helpers and functionality of the default editor.
Using this editor you can add whatever special character your keyboard supports without losing the default editor shortcuts.

To open the fallback editor use the Ctrl+q shortcut. Type whatever you want and use the same shortcut to update translation back to the default editor. Use Esc shortcut to cancel your edits in the fallback editor.


It there a way to fully disable the use of ‘special characters’ in the Transifex editor?

I currently have a translation string as follows (.strings file format):

"Action (↩)" = "Action (↩)";

However if I enter the character in the editor, when I hit ‘Save’ it gets saved as \r - not what I want:

"Action (↩)" = "Action (\r)";

There seems to be no way to enter the character in the editor.

Hello @pjrobertson ,

Thank you for reaching out to Transifex support.

According to our current parser’s behavior, what you described is expected and aligned to Apple strings specifications.

Is the current behavior breaking your workflow somehow? Any additional information you can share with us would be helpful so as to better understand the issue you are facing and try to find a way to address this for you.

Changing parser’s behavior is not an easy decision to take as any change may highly impact other users’ workflow.

Looking forward to your response.

Kind regards,

Thanks for the response! Perhaps I haven’t explained my problem clearly enough.

I have strings that need to be translated that contains the following UTF-8 character:

However, the parser is converting to \r. This means, that if I ever want to use the literal character in my translated strings, I cannot - they always get converted to \r.

In my mind, the parser should be able to detect if a user has entered the character, and then not convert it to \r.

Although never mind, I will just add a new build step in my build process to convert all \r to in the .strings files

EDIT: see here for what I mean: Update strings files (change \r to ↩) · quicksilver/Quicksilver@8e73d9c · GitHub

Hello @pjrobertson ,

Thank you for your feedback.

I will pass it along to the product team in order to investigate it further.
It’s good that you created the workaround you shared above.

Kind regards,