PiXeL16 / IBLocalizable

Localize your views directly in Interface Builder with IBLocalizable
MIT License
459 stars 48 forks source link

Uppercase and Capitalized? #6

Open gmarm opened 8 years ago

gmarm commented 8 years ago

I have been using a similar solution to what IBLocalizable does for quite some time using user defined attributes, although not having to define user defined attributes myself is admittedly so much cooler!

Over time, I realized that I was creating outlets just so I can capitalize or uppercase the localizable properties of UI elements, so I added a few extra methods for handling that. Something like:

func setLocalizedUppercaseText(_ text: String) {
    text = NSLocalizedString(text, comment: "").uppercased(with: Locale.current)
}

Do you think something like that, implemented according to IBLocalizable's architecture would make sense to be added?

PiXeL16 commented 8 years ago

Hey @gmarm. Thats nice! sure, that would be something that people will like to have I think. How would you image it it will work in IB? With a couple of checkbox with Uppercased and Capitalized along with the text?

gmarm commented 8 years ago

Yes that's how I initially approached it, however it didn't work.

I tried adding a capitalized and uppercased property to the Localizable protocol and then using their values in the applyLocalizableString(_ localizableString: String?) method to set the text according to their values. This couldn't work however, because Swift does not allow for stored properties in extensions (unless you do it in a hacky way that I really didn't want to go for), therefore I couldn't create functional @IBInspectable properties for capitalized and uppercased in the UI element extensions.

I did manage to make it work in a quick and less elegant way as can be seen here https://github.com/gmarm/IBLocalizable/pull/1, however I'm not happy with result. There are now three @IBInspectable properties (two more than before, for capitalized and uppercase localizable strings) and the consumer can set any one of them. The disadvantage of this is that as mentioned there are three properties and the consumer is supposed to only set one, which is not made clear. Since I wasn't really content with the result, I didn't create a PR for your repo.

I would very much prefer to somehow get it working with an approach similar to the first one. If you have any ideas, lets discuss.

PiXeL16 commented 8 years ago

Yes, like you mention you cant do stored properties in extensions without being hacky.

How about instead of using localizableStringToCapitalize we have boolean properties as capitalized and uppercased defaulting to false and then the applyLocalizableString method will just check those values and modify the localized text accordingly.?

Thats a little better, no?

gmarm commented 8 years ago

As I said, that's what I initially tried, unless I'm missing something you're pointing out.

My main problem was the implementation of

@IBInspectable public var capitalized: Bool {
    // implementation?
}

for example in the UIView's Localizable protocol conformance.

HamzaGhazouani commented 7 years ago

@gmarm may be you can try something like that ;)

 @IBInspectable public var uppercased: Bool {
        get {
            return false
        }
        set {
            if newValue == true {
               localizableString = localizableString.uppercaseString
            }
        }
    }
gmarm commented 7 years ago

@HamzaGhazouani Thanks, that's interesting.

Although, is there any guarantee that setting uppercased will get called after setting localizableString? 😕

HamzaGhazouani commented 7 years ago

Hi @gmarm, you should be sure that the uppercased is below localizableString in the User Defined Runtime attirbutes. it's not a real solution but a workaround... :/