ctxppc / silica Goto Github PK

Silica should try to re-associate localised string entries after a LocalisableString type (or a property thereof) has been renamed since the last run of the Silica tool. Currently any renames result in the previous localised string entries becoming disassociated (and marked with a “Unused” comment) and new (empty) localised string entries being created, requiring manual re-association.

Since Silica doesn’t retain source information and doesn’t participate in refactoring tools, it cannot know what renames have occurred. It can however heuristically determine what renames might have occurred by introspecting the unused localised string entries and trying to match them to newly created localised string entries. Silica should work pessimistically and only re-associate a localised string entry when either a single type, a single case, or a single property (across the whole codebase) has been renamed between runs of the Silica tool. In addition, it should emit a warning (once) notifying the developer that such re-association has been performed.

As an example, given the following code:

enum CarColour {
    case red
    case blue
}

Silica generates the following entries:

"CarColour.red" = "red";
"CarColour.blue" = "blue";

After renaming the type to CarColor (but no other LocalisableString type or a case or property thereof), Silica should generate the following entries:

"CarColor.red" = "red";
"CarColor.blue" = "blue";

and emit “warning: Silica re-associated string entries from type ‘CarColour’ to ‘CarColor’”.

Silica currently parses and analyses every source file as part of its localisable string extraction process, significantly slowing builds on larger projects that use Silica as part of the build process. To counter this effect, Silica should cache analysis results from source files and avoid parsing sources that haven’t been touched since the last run.

Specifically, Silica should maintain a cache file in the source root (or at a path given with the --cache command argument) that enumerates the localisation string identifiers extracted from each source file alongside a hash value of the source text. This cache file is versioned for Silica and invalidated when a different version of Silica is used. The cache file doesn’t need to be checked in version control repositories.

Silica should insert documentation comments next to the localisable string entries.

The following example:

/// A title used on an item in the tab bar.
enum TabItemTitle : LocalisableString {
    
    /// The tab title for popular videos in the user's vicinity.
    case nearby
    
    /// The tab title for videos popular with the user's friends.
    case friends
    
    /// The tab title for all-time popular videos.
    case allTime
    
}

/// A title used in a screen mentioning the user.
enum UserTitle : LocalisableString {
    
    /// The user isn't logged in.
    case notLoggedIn
    
    /// The user is logged in as `nickname`.
    case loggedIn(nickname: String)
    
}

should emit the following localisable string entries file:

/** TabItemTitle — A title used on an item in the tab bar. **/

/** The tab title for popular videos in the user's vicinity. **/
"TabItemTitle.nearby" = ""

/** The tab title for videos popular with the user's friends. **/
"TabItemTitle.friends" = ""

/** The tab title for all-time popular videos. **/
"TabItemTitle.allTime" = ""

/** UserTitle — A title used in a screen mentioning the user. **/

/** The user isn't logged in. **/
"UserTitle.notLoggedIn" = ""

/** The user is logged in as `nickname`. **/
"UserTitle.loggedIn(nickname: %@)" = ""

Silica should support associated values with types with finite inhabitants, more specifically enum types whose cases either don’t have associated values or whose associated values have value types with finite inhabitants (recursively), and the Bool type (with inhabitants false and true). It should generate localised string entries for all possible combinations. For example,

enum CarColour {
    case red
    case blue
}

enum Vehicle : LocalisableString {
    case bus(seats: Int, isDoubleDecker: Bool)
    case car(colour: CarColour, doors: Int)
}

should map to the localised string entries (with localiser-provided values):

"Vehicle.bus(seats: %ld, isDoubleDecker: false)" = "A normal bus with %ld seats"
"Vehicle.bus(seats: %ld, isDoubleDecker: true)" = "A double-decker with %ld seats"
"Vehicle.car(colour: .red, doors: %ld)" = "A red %ld-door car"
"Vehicle.car(colour: .blue, doors: %ld)" = "A blue %ld-door car"

If #1 is implemented, this support should be also extended to properties with value types with finite inhabitants.

Silica should perform an exhaustiveness check and limit the number of combinations (outputting a warning when the limit is exceeded). An option should be made available to change the limit (or outright disable it).

A future direction is to allow associated values with value types conforming to LocalisableString (possibly with infinite inhabitants).

Silica should add support for struct types conforming to the LocalisableString protocol, for when multiple cases for some string aren’t applicable.

As an example,

struct Sandwich : LocalisableString {
    var count: Int
    var extraIngredient: String
}

should result in the following localised string entry (the value being provided by the localiser):

"Sandwich(count: %ld, extraIngredient: %@)" = "%ld sandwiches with %@"