Question on correct use of #bc-ignore!

[donnellyk]

I'd like to use #bc-ignore! in Interface Builder. For mostly personal preference, I'd rather put it in the comment section, rather then the actual value of a label.

This works, and looking at StringsFileUpdater.swift, it doesn't seem to make a difference between keys and comments when looking for the special ignore strings.

I just want to confirm this is expected behavior. I don't want to depend on anything undocumented that might break in the future.

Thanks for all the work on this library, it is exactly what we needed.

[Jeehut]

Hi donellyk, thank you for your question. To be honest, I didn't know you can add comments to labels in Interface Builder, but this sounds very interesting. I might use this myself in the future, thanks for the pointer!

Having that said, that it works just out of the box is thanks to @kafejo who requested #15 and implemented it himself in #16, so having comments work is part of BartyCrouch since version 3.1.0. Also note that there is even a test written by @kafejo here which will make sure this feature doesn't break in the future, that should also make sure comments in Interface Builder keep working (so long as they are extracted as comments to the .strings files).

I hope this answers your question. Please let this issue open as I want to add this usage possibility to the README and this serves nicely as a TODO for that.

I'm happy this library is useful to you!

[donnellyk]

Great, thanks for the feedback.

[Jeehut]

Closing this as the question was answered.

[romanr]

This is a life saver! This must be added to the documentation.
When you add #bc-ignore! to label it stays this way in build output. and there's no other workaround but this.

[romanr]

@Dschee please add this to documentation. Allowing to add #bc-ignore! to comment is essential.

[Jeehut]

Could you explain why you would need a label text to be untranslatable which you don't want to set in code? I'd like to understand the use case. Cause if you want to set it in code, it's not important what stands in the label in interface builder.

I'm actually not a fan of using #bc-ignore! via the interface builder comments as it adds a very hardly debuggable source of potential problems. Say someone new enters your project and for some reason needs to make the label translatable again. He will ask himself why it doesn't appear in the localization files of your Storyboards, understand what I mean? If he would see #bc-ignore! he would probably think that's the reason (due to the ignore) and make a web search or just remove it. I don't want to introduce hidden problems if they are not necessary.

[romanr]

Let's say you design a storyboard view that displays user information.
And there's placeholder label where email would appear. Label text is placeholder [email protected]
We don't want this to appear in translation, so we change label text [email protected] to [email protected] #bc-ignore!
While it does not appear in translated languages, it appears as [email protected] #bc-ignore! in default base language (en) when app is run in English, on user's screen.
We can make it disappear if we change strings and nullify or remove that string.

In project we have tens of such strings that are not supposed to be translated. Instead of lot of manual work we simply add #bc-ignore! it to "Comment" field of label and it works fine.

Regarding your comment about possible confusion with #bc-ignore! comments - if it's a serious documented project you have #bc-ignore! mentioned in project Readme and developer guidelines. Responsible developers will be aware of that rule, it's not a problem.

Please don't disregard #bc-ignore!. I found this project because of this possibility to exclude strings from translation and this is the only tool that does it automagically.

Thank you for the great tool.

[Jeehut]

I do not disregard #bc-ignore!, not at all. But I always meant it to be included in a way that everybody will immediately see it's there in the Storyboard, not somewhere in the properties. Your example with the email placeholder is a perfect example for a string that should be translated – I would never use a .com TLD or the name user in a view translated to German. And I think you are misunderstanding me: Maybe in your company every "responsible developer" is expected to read the entire README. But I'm pretty sure there are many developers, who are "responsible developers" and want to contribute a single feature on an open source project – I don't think they should be required to read the entire READMEs of all frameworks and tools used. The errors should be self-explanatory if possible.

Having this said, this is also an open source tool, so if you feel like others would profit from such a feature being documented, feel free to create a PR with an explanation. I would probably merge it. I just don't want to invest time in something I don't believe in. I hope you can understand this. ;)