Reach more users worldwide without spending days or hundreds on app localisation. Localise your Xcode projects in minutes, reduce translation costs, and spend less time managing strings so you can focus on building great apps.
Hi,
I'm Melvin, the developer of App UFO.
I have been developing apps since 2012 & I know how important but frustrating App localisation is.
I am trying to solve this with AppUFO
Report
congrats on the launch, localisation is exactly the kind of chore that eats a weekend right before you want to ship. one thing I'm curious about beyond the plural rules question already asked - the same source string sometimes needs different translations depending on context, like "Save" as a button vs "Save" as a noun in a settings label. does AppUFO give translators any way to see or add context for a string (comments, screenshot, surrounding key names), or is it working off the raw string key alone?
@galdayan it does have Ai context. It adds app context automatically from the appstore listing and auto comments per phrase generated by Xcode. You can also add character limit to respect ui. More detail in my vlog:
https://youtu.be/e6iX2eOHOHc
localisation is one of those things that always takes way longer than it should, so this is a welcome idea. curious how it handles plural rules and gendered strings though - languages like Arabic or Polish have way more plural forms than English, and that's usually where automated localisation tools fall apart and produce grammatically broken UI text. does AppUFO handle that at the ICU/stringsdict level or is it more of a straight string-for-string translation?
@omri_ben_shoham1 it does handle plurals, variables.. and it produces an accurate translation using the GPT5.6
Report
The App Store context pull is a smart move — working off bare string keys is where most localisation tools produce plausible-but-wrong translations. One thing I would want to check before wiring this into a CI pipeline: does AppUFO support the .xcstrings (String Catalog) format that Xcode 15 introduced, or is it still expecting the older .strings and .stringsdict files? That migration path is usually where these tools either save or cost extra time on existing projects.
@hi_i_am_mimo it does support the new xcstrings file. You just drop it in
Report
That's the answer I was hoping for — drop-in support means zero migration friction. One quick follow-up: does AppUFO read the sourceLanguage declared in the .xcstrings file itself, or does it require you to set the source language separately in the tool?
Report
Pulling context straight from the App Store listing instead of asking translators to work off bare keys is a smart shortcut - didn't realize it went that route. That should cut down a lot of the ambiguous cases without needing a whole review workflow.
@reda_roqai_chaoui i haven’t yet. But I only just started using it. Looking forward to get some results. Results i saw from other devs are impressive in terms of app store aso
TinyFast
congrats on the launch, localisation is exactly the kind of chore that eats a weekend right before you want to ship. one thing I'm curious about beyond the plural rules question already asked - the same source string sometimes needs different translations depending on context, like "Save" as a button vs "Save" as a noun in a settings label. does AppUFO give translators any way to see or add context for a string (comments, screenshot, surrounding key names), or is it working off the raw string key alone?
TinyFast
TinyFast
localisation is one of those things that always takes way longer than it should, so this is a welcome idea. curious how it handles plural rules and gendered strings though - languages like Arabic or Polish have way more plural forms than English, and that's usually where automated localisation tools fall apart and produce grammatically broken UI text. does AppUFO handle that at the ICU/stringsdict level or is it more of a straight string-for-string translation?
TinyFast
The App Store context pull is a smart move — working off bare string keys is where most localisation tools produce plausible-but-wrong translations. One thing I would want to check before wiring this into a CI pipeline: does AppUFO support the .xcstrings (String Catalog) format that Xcode 15 introduced, or is it still expecting the older .strings and .stringsdict files? That migration path is usually where these tools either save or cost extra time on existing projects.
TinyFast
That's the answer I was hoping for — drop-in support means zero migration friction. One quick follow-up: does AppUFO read the sourceLanguage declared in the .xcstrings file itself, or does it require you to set the source language separately in the tool?
Pulling context straight from the App Store listing instead of asking translators to work off bare keys is a smart shortcut - didn't realize it went that route. That should cut down a lot of the ambiguous cases without needing a whole review workflow.
TinyFast
I'm wondering if you've seen an increase in users from new markets after localizing with your tool.
TinyFast