Feature requests

Sorry for the mostly AI generated bug report and its stupid formatting (my own attempt at explaining the issue was just gibberish so this is better than that), and hopefully this is an okay place to leave bug report,s but we have a weird issue on Android after updating to usage of Github App Summary The SimpleLocalize GitHub App download writes identical Swedish (sv) content to all three language files (en, fi, sv), ignoring the language-key mapping in simplelocalize-github.yml. The dashboard shows correct translations for all languages — the issue is only in the download output. Environment Platform: Android (android-strings format) Integration: SimpleLocalize GitHub App Languages: en, fi, sv | Default: en | Fallback: None Also in repo: simplelocalize.yaml (legacy CLI config) Configuration simplelocalize-github.yml (download section) download: pull-branch: "develop" push-branch: "simplelocalize/translations" files: - path: "client/src/main/res/values/strings.xml" format: "android-strings" language-key: "en" options: [WRITE_NESTED, INCLUDE_DESCRIPTIONS] - path: "client/src/main/res/values-fi/strings.xml" format: "android-strings" language-key: "fi" options: [WRITE_NESTED, INCLUDE_DESCRIPTIONS] - path: "client/src/main/res/values-sv/strings.xml" format: "android-strings" language-key: "sv" options: [WRITE_NESTED, INCLUDE_DESCRIPTIONS] Legacy CLI config also present: simplelocalize.yaml downloadPath: ./client/src/main/res/values-{lang}/strings.xml downloadLanguageKeys: ['fi', 'sv'] Expected vs Actual Expected: Each file gets its own language (en -> values/, fi -> values-fi/, sv -> values-sv/). Actual: All three files are byte-for-byte identical, all containing Swedish: <!-- values/strings.xml — should be English --> <string name="action_generic_cancel">Avbryt</string> <!-- should be "Cancel" --> <string name="action_continue">Fortsätt</string> <!-- should be "Continue" --> <!-- values-fi/strings.xml — should be Finnish --> <string name="action_generic_cancel">Avbryt</string> <!-- should be "Peruuta" --> <string name="action_continue">Fortsätt</string> <!-- should be "Jatka" --> What We Verified - Dashboard translations are correct for all languages - Default language is English, fallback is None - language-key mappings in config are correct - Source files on develop branch contain correct English - The old integration (GitHub Actions + CLI) worked correctly Timeline Mar 13 │ Last update via old CLI workflow -> Correct Mar 20 │ Migrated to GitHub App -> No download yet Mar 26 │ First GitHub App download -> All files Swedish Mar 31 │ 4th language (German) added then removed -> Still all Swedish The GitHub App has never produced a correct download since migration. Possible Issue From Our Side The legacy simplelocalize.yaml has downloadLanguageKeys: ['fi', 'sv'] (no English). If the GitHub App reads or merges this file, it could cause language resolution issues — but shouldn't produce identical Swedish in all files. Steps to Reproduce Project with 3 languages (en, fi, sv), default English, no fallback Use simplelocalize-github.yml config as shown above Have simplelocalize.yaml CLI config also present in repo Trigger a download / publish All three output files contain identical Swedish

Sometimes, even if in the Figma Plugin the option to upload screenshots is checked, when pushing keys to SimpleLocalize, the screenshots are absent from the keys.

Hi SimpleLocalize team, I found an inconsistency in how apostrophes are escaped in Android XML strings when HTML tags are present. Working case (plain text): When a translation contains an apostrophe without HTML tags, e.g.: libère de l'espace After syncing with Android Studio, the output is correctly escaped: <string name="example">libère de l\'espace</string> ✅ This compiles fine. Broken case (text with HTML tags): When the same translation contains HTML tags, e.g.: libère de <b>l'espace</b> After syncing, the output wraps in CDATA but drops the backslash escape: <string name="example"><![CDATA[<b>libère de l'espace]]></string> ❌ This fails to compile because the unescaped apostrophe breaks the Android XML parser. Expected behavior: Either: Escape the apostrophe inside CDATA: l\'espace Or use XML entity instead of CDATA: libère de &lt;b&gt;l\'espace&lt;/b&gt;

Previously, editing a customer-specific translation only affected that customer. Now, when I edit a translation key in a customer context, the default translation is updated as well. How to reproduce: Open the project with customers Toggle the customer visibility Edit a translation value for this customer => the main translation is updated as well Expected result: The change should only apply to the customer-specific translation. The default translation should remain unchanged. It’s currently impossible to maintain customer-specific overrides without modifying the default translations.

Long namespace names (e.g., 192 characters) clutter the Web UI and break layout. We should truncate them (e.g., to 30-40 chars) and show the full name on hover as a tooltip for better readability and UX.

Steps: Create a translation key called "[" or "]". Try to rename the translation key to "a". Expected: The translation key will be renamed to "a". Actual: "We couldn't update the translation key metadata"

The schema of the 200 response of https://api.simplelocalize.io/openapi/swagger-ui/index.html#/Translations/updateTranslationsV2Bulk is { "msg": "OK", "status": 200, "data": { "failures": [ { "entry": { "key": "string", "namespace": "string", "description": "string", "codeDescription": "string", "charactersLimit": 0, "tags": [ "string" ] }, "message": "string" } ] } } but the actual response I get is { "msg": "OK", "status": 200, "data": { "failures": [ { "entry": { "key": "foo", "language": "en", "text": "bar", "namespace": "baz" }, "message": "Translation key not found" } ] } } The properties "language" and "text" do not appear in the schema.

Estonian language code is et and it seems that this is used as the country code to look up the flag because Ethiopian flag is shown. When I change to et_EE then Estonian flag is shown but I think it should work with just et as well because there is no other locale with that language code. Same issue with sv and probably others. Also after the flag has been corrected then when going back to edit the wrong flag is displayed again.