Installer bartycrouch avec Homebrew

Liens du projet

• Page d'accueil
• Docs amont
• Page du gestionnaire de paquets

Commandes et alias

• bartycrouch

Historique du projet

The public GitHub repository was created in February 2016 and the README describes BartyCrouch as an automation-friendly command-line tool for Xcode localization workflows. The project grew with Swift and Xcode releases, with the changelog showing recurring updates for SwiftSyntax, Xcode compatibility, DeepL and Microsoft Translator support, and performance fixes.

By the 4.x series, BartyCrouch had become a fairly complete localization workflow tool: it could update interface and code strings, normalize and lint localization files, transform helper calls, and optionally machine translate entries through configured translation services.

Historique d'adoption

The official README documents Homebrew and Mint installation paths, placing BartyCrouch in the common Swift CLI tooling ecosystem. The Homebrew formula and the input package metadata identify it as a packaged executable named bartycrouch.

The README now points out that Apple's Xcode 15 String Catalogs cover many of BartyCrouch's historical use cases, and says BartyCrouch is kept current mainly by community volunteers. That makes its current adoption story partly legacy maintenance for projects still using .strings workflows and partly a bridge for teams that want machine translation around Apple localization files.

Modes d'utilisation

Typical use starts with bartycrouch init, which creates .bartycrouch.toml in the project root. Users then run update and lint tasks manually or wire BartyCrouch into an Xcode build script so localization files stay synchronized with source and Interface Builder files.

The same configuration file can contain translator settings and secrets for machine translation, so it is both a project configuration surface and, when translation is enabled, a credentials-bearing file.

Pourquoi les passionnés de paquets s'y intéressent

BartyCrouch is interesting because it sits in the narrow but important space between Xcode resource files, Swift source parsing, and package-manager-distributed developer automation. It is also a small example of how Homebrew carried specialized iOS/macOS tooling before Apple added comparable first-party workflows.

For package historians, the project tracks the churn of Swift tooling: SwiftSyntax versions, Xcode releases, and localization file formats all shaped its releases.

Chronologie

• 2016: Public GitHub repository created for BartyCrouch.
• 2019: 4.x releases added Swift 5 and Xcode 10.2 support.
• 2021: DeepL support was added alongside Microsoft Translator support.
• 2022: Swift 5.7 and Xcode 14 support landed in the 4.14 series.
• 2023: 4.15.0 updated translation and SwiftSyntax support; the README later noted Xcode 15 String Catalogs as the recommended future direction.

Related projects

• Apple String Catalogs are the first-party Xcode feature that now overlaps with much of BartyCrouch's incremental extraction and empty-translation warning workflow.
• SwiftGen appears in the README as an integration point for teams using generated Swift accessors for localized strings.
• TranslateKit is recommended by the BartyCrouch README as a newer companion path for machine translation of String Catalog files.

Sources

• https://api.github.com/repos/FlineDev/BartyCrouch
• https://github.com/FlineDev/BartyCrouch#readme
• https://github.com/FlineDev/BartyCrouch/blob/main/CHANGELOG.md
• source_facts.package-manager