liamnichols / xcstrings-tool Goto Github PK

The code can theoretically generate into projects that support < iOS 16, so we should include the appropriate availability headers.

A string like this:

Results in Swift code like this:

We should use #"Golden "Good Boy" Retriever"# or escape the relevant characters 🤔

I don't want anybody to feel locked-into a third party tool, and they're not. But because the source code isn't copied into the repo, it's not clear that you can obtain it.

Add an article with explicit instructions on how to copy the generated source out and deintegrate the tool if you wish.

The majority of tests for the tool are implemented using snapshot tests, but its not clear to new contributors how to go about utilising them (ref: #22 (comment))

It would be good to include some instructions in CONTRIBUTING.md to help make it easier for people.

There are two good topics to cover here:

1. Converting existing .strings files into a Strings Catalog
2. Using the compiler collected strings list to bootstrap your manual strings

I would guess this should actually result in a UInt argument?

I'm guessing this is where this is currently decided:

Is there any argument why %u should not result in UInt or is this a bug?

It seems like the nullability requirements are too strict in the current implementation.

I'm seeing entirely empty objects representing some strings so it seems like a key alone is apparently enough.

First off, I was about to write a similar plugin before I did a quick search and found yours. Glad I did because this looks great! 👏

I'm looking into replacing the use of SwiftGen in a project I'm working on with this plugin but there are two features I'd need before being able to do so. Before contributing I'd like to gauge interest to see whether you think the features are suitable additions to your plugin. These are:

• The ability to parse legacy string files (for those who haven't migrated to string catalogs).
• The ability to fall back to a base localization if translation isn't complete. So for example, going with the English string if the German counterpart is missing.

What do you think? To be clear, if these features are something you think would be valuable additions I'm more than happy to contribute.

I found a "*" key was converted to "" and it caused the generation of invalid code. We should catch this earlier and error.

There are two scenarios where we ignore strings in a catalog:

1. A value is missing in the source language
   • This is common if the key is the phrase
2. The key is automatically managed
   • This happens when the compiler is syncing the key from Swift source code

We have to ignore these keys because it means that they typically haven't been properly defined by the developer can't cant be represented in Swift, but ignoring them with no warning can leave the developer confused and frustrated when the Swift property cannot be found.

I've even confused myself about this a couple of time during development.

Because XCStrings Tool has strong opinions on using manually created strings with a key and default value, we should produce a warning that can help surface this misconfiguration and guide the developer to correct it.

A string like this:

Produces code like this:

Maybe it's better to use a multiline string literal? This will also fix #10 to some degree. But also the comments need to be fixed too.

It's in the readme, but it deserves an article.

Demo migrating Apple's Food Truck app.
A simplified version would also make a good tutorial.

Adding a note here for now because I forgot...

1. Bump the version (example)
2. Download xcstrings-tool.artifactbundle.zip from the workflow run for the version bump commit (example)
   • Make sure that it's not double zipped (unzip -l)
3. Compute it's checksum with shasum -a 256 <path>
4. Create a new release and include the artifactbundle and it's sha (see other releases as an example)
5. Update https://github.com/liamnichols/xcstrings-tool-plugin
   • Update the binaryTarget in Package.swift for the new version
   • Copy the plugin over if it was modified
6. Create a new release in the plugin repository
7. Update https://github.com/liamnichols/xcstrings-tool-demo

https://developer.apple.com/documentation/swift/codingkeyrepresentable

For the string catalog decodable implementation to replace the DictionaryWrapper type.

We use this type instead of a dictionary directly, because dictionaries with RawRepresentable keys do not decode properly by default.

I think making these RawRepresentable types conform to the CodingKeyRepresentable protocol will fix that and allow us to use Dictionary directly.

I have not confirmed this though

This is just an idea.

For organization, it would be nice to be able to write something like

Text(.localizable.settings.title)

I was wondering if this could not somehow be implemented by splitting the keys found in .xcstrings on the . character, and then generating nested static structs.

Thoughts?

Currently the plugin is defined as part of this repo, which means that dependant projects must bring in the entire xcstrings-tool repo and it's dependencies into their build graph.

This adds compilation time and i'm wondering if it could be avoided.

We could publish a binary artefact of the xcstrings-tool cli and instead host the plugin in a dedicated repo. This would give a few benefits:

1. We can lower the deployment target as the plugin doesn't use ResultBuilder or other macOS 13+ APIs
2. Using a binary dependency will significantly reduce compile times for other projects

But it also has some cons since it is another repo to maintain. I think we can automate most of this though to eliminate those issues.

We have errors surfaced in the issue navigator which is great, but they aren't linked to the .xcstrings file so clicking them takes you to the build log.

While we can't do line number navigation, it might be better if we take you to the file still?

When using this approach, you should be sure to turn off Use Compiler to Extract Swift Strings as it becomes a pain when they're automatically added back.

Currently the generator just throws stuff from JSONDecoder and Data etc, which isn't picked up nicely in the issue navigator.

I think we want to wrap run() and format errors consistently (or eliminate errors 😄)

Hey @liamnichols !

I downloaded your demo project DogTracker to test things out, and replaced the Localizable.xcstrings with our own (we have a lot of languages, and a lot of strings - the file itself has 12MB and ~600 000 lines).

When compiling the dog Tracker, error is shown:
Decoding error at ‘strings → common.feed.translations_seen_by → localizations → ar → substitutions → number_of_parents‘ - The data couldn’t be read because it is missing.

As you can see on the screenshot, everything looks correct. I wonder if you are able to debug this issue. Note: It is using 0.1.1 version released 30 mins ago. :)