Support other names than `Localizable.strings` as input (`tableName` parameter) about swiftgen HOT 12 CLOSED

Just to give some news: we're one step closer (well, very close in fact) for this to be finally supported! SwiftGen/SwiftGenKit#41

from swiftgen.

#24 is now merged: it should now be quite easy to make a PR to support this.

Ideas for the first steps to this:

• modify strings.swift here to inject the input file basename (without the .strings extension) in the stencilContext here.
• Then alter the default template here to use this new variable from the context (maybe make an exception if that variable is equal to the default Localizable table name?)
• Don't forget Unit Tests & CHANGELOG

Then next steps would be to fix #32 and #33 so that we can generate multiple enums at once in the same file, instead of having to call swiftgen once for each .strings to generate.

from swiftgen.

So, I thought about this considerably today, and ran into a few tricky issues.

In Swift, enums (and, so it follows, all of their cases) must be declared at compile-time. Said another way, we can't take advantage of composition to add cases to a previously-declared enum.

What this restriction means for SwiftGen users who are trying to generate a Swift enum type derived from a collection of separate .strings files is: all .strings files would necessarily have to be specified at SwiftGen execution-time. (This assumes we want to stick with generating a single, parent L10n enum type for strings, of course.)

I envisioned that would lead to a generated data structure interface that could look roughly like:

enum L10n {
    enum BaseTable { // i.e. Localizable.strings (special case)
        case AlertTitle
        case AlertMessage
        case Greetings(String, Int)
    }

    enum LoginTable { // i.e. Login.strings
        case SignUp
        case SignIn
        case ResetPassword
    }

    case Base(BaseTable)
    case Login(LoginTable)
}

(While we're at it, input welcomed on that interface, too!)

This would create a less flexible SwiftGen interface, but, on the flip side, it would provide a solution for something like #32.

Alternatively, if we want something more composition-friendly, we could switch the generated L10n data structure to a struct type and extend it with localization table-specific enums.

Thoughts?

from swiftgen.

Interesting interface.
I was more thinking about using a struct containing each enum, like that:

protocol Localizable {
  static var tableName: String { get }
  var localized: String { get }
}

struct L10n {
  func tr(table: String, _ key: String, _ params: CVarArgType...) {
    let format = NSLocalizedStringFromTable(key, table: table)
    return params.count == 0 ? format : String(format: format, args: params)
  }

  enum BaseTable: Localizable {
    static let tableName = "BaseTable"

    case AlertTitle
    case AlertMessage
    case Greetings(String, Int)

    var localized: String {
      switch self {
      case AlertTitle: return L10n.tr(BaseTable.tableName, "AlertTitle")
      case AlertMessage: return L10n.tr(BaseTable.tableName, "AlertMessage")
      case Greetings(let p0, let p1): return L10n.tr(BaseTable.tableName, "Greetings", p0, p1)
      }
    }
  }

  enum LoginTable: Localizable {
    ... /* same logic */
  }
}

func tr(key: Localizable) { return key.localized }
extension Localizable: CustomStringConvertible {
  var description: String { return self.localized }
}

Note: this code was typed directly in GitHub I'm not sure about the syntax and didn't check if it compiled, it may have some typos

Usage:

let g = L10n.BaseTable.Greetings("Joe", 5)
g.localized
tr(g) // this is just an alternative syntax
"I say: \(g)" // another one

Choice Criteria

I think we should focus on having a beautiful syntax at the call site, no matter how the generated code is structured. But one of the challenges here is also to have a tr() function being able to handle an enum representing any table. We can't have a tr(key: L10n) anymore if we split that into different enums as the key we are passing is not an L10n but an L10n.BaseTable for example. That's why I introduced the Localizable protocol here.

I'm curious about how your tr implementation would look with your solution using enums with associated values. Could be an interesting brainstorm.

I'd prefer the syntax at call site to be L10n.Base.Greetings rather than L10n(Base.Greetings), but your solution seem interesting too. Thoughts?

from swiftgen.

Thanks for the feedback, Olivier!

Actually, I'm not married to any particular approach. After looking at your suggested interface, I agree that does look like a clean approach (and makes call site syntax more elegant).

With that in mind, PR added: #86

from swiftgen.

looking forward to use it

from swiftgen.

What is the current state for supporting tableNames?

from swiftgen.

@beseder42 It's already implemented and works in master. To be honest with you I'm not sure since how long we have implemented it and if it already made into the latest 4.2.1 release a while ago… or if it's still pending in master ready for the very-soon-upcoming-but-not-yet-released 5.0.0.

I'll close this current issue because I know for sure that this feature has been implemented already, at least in master; I'll investigate more in a few about when we did that and in which version we added this support (if it has already been released or if it's still pending in master), as it seems that we forgot to mention that in the CHANGELOG when we added it.

\cc @djbe if you have a better memory than I do about when we added that support

from swiftgen.

@AliSoftware it was added in this commit: 937b2c5

Edit: oh you probably mean the template support, let me search for that.

from swiftgen.

🤔 That's strange because that commit seems to be before 4.2.1 but when I try swiftgen strings -t swift3 -o test.swift Loc.strings with 4.2.1 it doesn't seem to take the Loc tablename into account…

from swiftgen.

Yeah, misunderstood the context. It was added in SwiftGen/templates#49

from swiftgen.

Ah, right (strange, I looked at the templates' CHANGELOG too but missed it). So it's only in templates 2.0 which will only be available/usable with SwiftGen 5.0 then

from swiftgen.