Today when we generate the keys and intermediate enum types in both our strings templates, we normalize those keys to respect Swift conventions: conversion from snake_case to camelCase, uppercase the name of enum types, lowercase static let constant names.
So in the structured template, a key like shop_status.alert_title will generate enum ShopStatus { static let alertTitle = … }
A lot of people (and I find myself being more and more in that group too tbh) would prefer to keep the keys verbatim, even if that means not respecting the Swift conventions for naming enums and static let in the generated code; so that we'd instead generate enum shop_status { static let alert_title = … }.
That way the generated constants look the same at call site as what's in the strings file, as we'd reference the key "shop_status.alert_title" using L10n.shop_status.alert_title instead of L10n.ShopStatus.alertTitle (which seemed less consistent to me at call site, especially with only the last leaf being lowercase)
Related issues: #465.
So the solution would be to provide a param to allow people switching between the two modes.
Honestly I'm even wondering if we shouldn't make that verbatim mode the default and opt-out (then the param would be called standardizeNames = true or swiftifyNames maybe?) rather than making it opt-in (param could then be named keepNamesVerbatim = true?).
Sure that would be breaking but I think more people would find that default more logical (after all if you don't find your keys Swifty enough it's your responsibility to rename them in the strings file), and breaking this templates would make the param discoverable — as long of course as it's described in the migration guide for those not yet ready to migrate to verbatim mode or who would like to stay on the current mode)
Totally agree that this behaviour should be available to the users, but I disagree that we should make this the default. Shouldn't SwiftGen generate nice, swifty constants by default?
When you currently edit the Info.plist in Xcode, by default it will show "nice names" for each key (and value) where possible. In the info window you can always see the "raw" names/values, and you can right-click to toggle "show raw keys/values".
Following that naming, I'd propose a rawKeys parameter (flag).
Good point on nice names.
In that regard I'm ok to not making it the default and rawKeys looks good to me as the param name
I think what I dislike the most though is that since enum names are capitalized while leaf static let names aren't, making even the pretty-fied names inconsistent. It's neither L10n.ShopStatus.AlertTitle nor L10n.shopStatus.alertTitle, but a mix in-between, just in order to respect the Swift conventions that names of types should start with an uppercase, while in practice nobody use those non-leaf enums as types directly (very few people even realize they are enums), and most people probably always reference directly from L10n.… all the way down to the leaf constant anyway…
But maybe that's another debate, or another mode (strict = current mode resurrecting Swift conventions, camelCase would be same as today but with enums not capitalized, and raw = keys verbatim?!)
Before we go that route (and I think we might as well do this, the template impact is pretty minimal), I think we have to take a look at our current swiftIdentifier filter.
By default, our current filter will always uppercase the first letter, that's going to need to change.
Indeed (I wonder why we uppercased in that implementation of that filter in the first place btw). That's gonna need a breaking version of StencilSwiftKit then.
It shouldn't be a breaking change, see https://github.com/SwiftGen/StencilSwiftKit/issues/101 for more information.
Most helpful comment
Totally agree that this behaviour should be available to the users, but I disagree that we should make this the default. Shouldn't SwiftGen generate nice, swifty constants by default?
When you currently edit the Info.plist in Xcode, by default it will show "nice names" for each key (and value) where possible. In the info window you can always see the "raw" names/values, and you can right-click to toggle "show raw keys/values".
Following that naming, I'd propose a
rawKeysparameter (flag).