Proposal: exclude pattern

[SimplGy]

Wonder what you think of an exclude pattern?

When I build storyboards or xibs, often I'll put in text as a placeholder, but it'll never be seen because it's replaced when real data loads in (and in these cases, I often set the text to nil when the outlet is didSet so that the user doesn't see a flash of placeholder text). The placeholder text is useful in interface builder because it helps me do the layout and remember what fields go where.

I'm looking for a way to exclude them.

For our translator, the convention we came up with is if the text is surrounded by [brackets], then don't worry about it. We tried ~~placeholder~~ comments in storyboard but I'd forget them, and they move with copy+paste so they get stuck on the wrong fields.

I love the Only non-translated feature, but once we have most of the app done it's hard to separate the placeholder fields from the ones that still need translation.

Live data, whole app now translated:

Do you think this is a problem others will have and is worth solving, or am I doing something to put myself in a unique situation?

I recognize an exclude box that takes regex would overlap in a possibly odd with with the existing filter. Ideas:

• Maybe exclude is a field you can fill in on a settings screen, persisted across files and projects?
• Maybe filter box can accept a negated regex pattern? eg: ^[^\[] ?

Maybe not generalizable enough in need or priority. No hard feelings if you close, but using github issues always encourages me to do a bit more of a thoughtful write-up.

[remuslazar]

I just researched a bit, basically the translate="no" XLIFF attribute should mark items as "non-translatable":

• http://stackoverflow.com/questions/29007372/sane-localization-workflow-using-xcode-6-ios-8-storyboards-and-xliff
• http://stackoverflow.com/questions/23920633/mark-text-in-interface-builder-as-not-needing-translation

Unfortunately, Xcode does not handle that currently. A vague idea could be giving the user the opportunity to mark items as "non-translatable", setting this attribute accordingly in XML.
But because Xcode will just re-generate the xliff file on every iteration (and that's the way this tool is meant to be used), this information will be then lost, so it doesn't make any sense.

I like your idea with the exclude-pattern in app-settings, this could be the right pragmatic approach. Using this regex to mark all entries with translate="no", save the file, send the xliff file to the translator so the translator doesn't need the regex anymore to proceed, this being now encoded in the xliff file in a compliant way.

[remuslazar]

@SimplGy, on the other side, having the placeholder strings translated could help development quite a bit, by using the Storyboard-Preview Feature and rendering the Storyboard for different devices/orientations and also Localizations.
So instead of using the "Double-Length Pseudolanguage" the developer can just use the translated placeholder to get a more realistic picture of how the UX will look like in that particular language.

I should admit that I was not doing that in my projects, but I think the Xcode Preview Feature is something they introduced quite recently, in Xcode 8 or so.

[SimplGy]

Since xliff-tool is awesomely Free, Easy-to-use, and installs from the app store:

I was going to suggest the translators use it directly.

Not sure how to help them get an exclude pattern in place though. If it's a one-time setup I can just give them a pattern to paste in.

Or I can load the file, run an "exclude pass" on it that marks translate="no", and send them that xliff file, as you said. Maybe that's a good approach if web-based translation services support the xliff format in a complete way--not sure, I haven't used them.

I'm not sure I understand your point about translated placeholder strings. In all the cases I have them, the content of the string is unrelated to the data that will fill in later. For example, it might say Price or [$], but later fill in with $52.51--an actual price. Same with things like Item Title and Description of Item -- having longer or different translations of these placeholders is not very meaningful I think, because the actual text that fills in is totally unrelated.

We've been tempted to do translations for placeholders just to make it easy to see what "real" remaining work there is to do on translation, but great tooling would make that unnecessary.

[remuslazar]

IMO it is better to use some kinda "real world" data for the placeholder strings. Using your example, instead of using "Price" of "$", a string like "$12.45" could be used, this could be localized as "12,45€" for e.g. German. So it can also be checked if the width of the field/Auto Layout Constraints are ok for a particular language. Another example: Person name: "John Doe" could be "translated" to "Hans Mustermann" in German, the names also tend to be longer in German..

And sometimes it is also helpful the developer will put in the translation for a particular language, using the localized output from the .e.g NSDateIntervalFormatter so the translator will get a more accurate picture of how the output will look like at run tine and how other strings should accommodate that.

In many cases this approach seems inappropriate, when the data is e.g. not localized (user input) and you cannot predict what the field content of a particular item in a e.g. table will be, but it could help the developer to see how the app will "feel" for a particular language, having all placeholders also translated into that language.

All that said, I think this feature is still an interesting one, also because the XLIFF standard does support it. I wanted to use the opportunity to elaborate my thoughts about the workflow with the placeholder strings and not to supersede this feature request.

PS: @SimplGy, thank you for the flowers about xliff-tool :)

[SimplGy]

There are good arguments for a "realistic placeholder data" approach, but I prefer a "meta placeholder description" approach still. Why?

1. Fail fast

If I have $12.45 in the UI, and either because of forgetfulness or subtle failure do not nil it out and instead replace the placeholder value with real data when that data loads, the UI will show a flash from one price to another. This is unlikely to be noticed or reported as a bug (it's possible, but it's easier to identify a flash from [Price] to a real price as a bug). If the rule is "[...] never should show in the UI", related bugs are easy to identify.

2. Explicitness

By its nature, I only have one string of text available to describe what a field does, so I may choose to use either an example or a description. An explicit description is useful for subtle differences, like say "Menu Item with Thumbnail" vs "Menu Item without Thumbnail" or for differences where the same object is used in different contexts, such as "Order Owner's Name" vs "Current User Name". These differences can be hard to communicate only by example.

3. Obviousness

An original problem was figuring out which text is "placeholder" and which is not. If the plan is to translate everything that's ok. But there are other cases besides translation where you'd probably like to know if a UI field is placeholder or not. It's not always so obvious, even when looking at the storyboard--is "Discount Name" the label for something that will fill in underneath or beside it, or is that a placeholder for the actual discount name?

[remuslazar]

@SimplGy Thank you for sharing your rationale, now I also think that your "meta placeholder description" approach is the better one in most cases.

I will think about the implementation options already discussed here and will try to come up with an elegant one.. for the next major release then. Unfortunately I'm quite busy with other stuff right now, so I have to set priorities..

[SimplGy]

Wow, thanks for reading all that with an open mind. It's sort of tangental to the feature, but maybe related because if you don't have a recognizable pattern there's no regex you could write that would do any exclusion. This is probably solved by including comments in candidacy for exclusion, since you can set comments in both IB and code.

I'm busy too, but I think I could build it, if you'd like. I'd be more comfortable investing the time though if you choose which approach you think is best for the product.

Possible Approaches:

• Global Preference: App config/preferences field "exclude" accepts a string search or regex. This scans all fields including comments (so that if people want to use real content instead of meta descriptors for values they can still put ISPLACEHOLDER or something in storyboard comments)
• Hidden XML Node: For each file add an xliff-valid but-not-competing xml element or attribute is added to the xml, such as <xliff version='1.2' xmlns:xliff-tool-exlude='PLACEHOLDER'>
• translate="no": App config specifies an exclude pattern, and as soon as you save an xliff file this attribute is updated across all nodes. I don't love that just the xml file with translate=no nodes is not enough to reconstruct the exclude pattern. I do love that it's "blessed" by the standard. I have questions about how this would be implemented (save right away when you open? how often to rescan and update all the nodes? what if a different tool set translate=no, can we assume we can always clear and change existing translate=no attributes?)

[zoul]

I think the best place to solve this problem would be Xcode – there should be a checkbox to mark items as non-translatable in the Interface Builder. (Which would produce the translate="no" attribute in the exported XLIFF or leave out the node altogether.) It’s a shame that Apple didn’t add the feature since Xcode 6. What we can do is vote for the feature by reporting a feature request in Radar.

That said, it would still be nice to have some tooling support before the feature gets added to Xcode.

Updating the translate="no" attributes based on the current exclude pattern seems fragile. What if the pattern changes? Should all existing translate="no" attributes be cleared and set again? A global preference seems like a very simple solution, but it doesn’t solve the case where you want to filter the strings before sending them to the translators.

How about a new save (export?) command that would only save the currently visible lines? The rest could be either left out or disabled with translate="no". That should be both obvious and simple to implement.

[SimplGy]

If you only export visible lines, wouldn't that throw off your diff when you import it back in to xcode, or would it just ignore those?

[SimplGy]

I think if we did a global preference, then embedded it in the xliff file, it would work as long as my translator uses xliff-tool. That's good enough to solve my immediate problem. It's not a perfect solution, but without xcode support I don't see a better one.