Mismatched Translation

I'm experimenting with github actions, xcodebuild -exportLocalizations / xcodebuild -importLocalizations and the web application lokalise.com, trying to automate the localisation process for my app.

As a test I marked all my storyboards as localisable with base (english) localisation, exported the .xcloc and imported it into lokalise. Lokalise correctly imports this as English and shows all the keys / values.

If I make any change to the English translations as a test (such as adding a "$" to the end), Lokalise changes both source and target inside the xliff

<trans-unit id="JOQ-R1-RUU.text">
    <source>Total $</source>
    <target>Total $</target>
    <note>Class = "UILabel"; text = "Total"; ObjectID = "JOQ-R1-RUU";</note>
</trans-unit>

I'm assuming this is what I would want. Given English is my base language. I would want my storyboard to update and display this new value while i'm working on it, not just on my app when its set to English.

However when I import (either manually or via command line) I get a warning about a mismatch with no option to accept the new value. Importing just ignores it and does nothing.

Is there no way to tell Xcode that this is what I want, accept the change?

Up vote post of simonmcl Down vote post of simonmcl
1.2k views
Posted by
simonmcl
Reply
Add a Comment

Replies

Unfortunately, this seems like a bug in your translation tool. The value of <source> reflects the "source of truth" value as it appear in your Base-localized Storyboard. You can update English independently of this, but you should only edit <target>. If you need to update the "source of truth", you need to edit this directly in your Storyboard and not via a translation tool.

Posted by
Frameworks Engineer
Post not yet marked as solved Up vote reply of Frameworks Engineer Down vote reply of Frameworks Engineer

  • So i've tried 3 other popular translation tools, and they have the exact same problem. There are now blog articles from these companies saying apples implementation of the .xliff standard is different in meaning to everyone else, and they've advised their users to not use these feature in iOS. To instead stick to using .strings files

    Based on my limited understanding of this, I think I agree with them. Whatever I type into my storyboard is stuck there forever unless manually updated by hand, any attempt to update automatically is ignored? What about typos? or wanting to keep the IB image up to date with the latest english values to avoid developer confusion? I can see many cases where I would want the <source> to be updated. I definitely see it as a flaw/bug/oversight that there is no command line argument and/or button in the UI to say "yes I understand the risks, update all the source values to match the import". For it to simply be ignored and receive a silent warning in command line leaves no wiggly room. If tools manage the task of updating <source> across all the languages, I don't see why that should be a prevented workflow

    —
    simonmcl
Add a Comment