Downloaded files should keep formatting and structure of uploaded source file

On Android String Res: If downloading the uploaded source file, because strings have changed in Localazy, then the whole structure and formatting of the originally uploaded file is no longer there. The string comments are all gone, the order is now alphabetically and all string values of the XML tags contain additional " characters at the start and end of the value.

Instead, it would be great to keep a version of the uploaded source file and simply replace the string values, if values are updated on Localazy. That way when downloading the file, the original content, structure and formatting are still present in the downloaded source file.

Building upon that idea, it would be even better if translated files that are downloaded simply take over the same structure (including order, comments & no additional formatting like ") and only replace the value section as well. That way the downloaded & integrated files that are then in the repository can all have the same level of quality and readability. And you can then also much easier use features of the IDE to support by finding localization issues that are only visible after building the app.

Hello @Erik,
Could you please tell us how does your translation workflow look like?

When the UI is build, then the strings are part of that design for the English language. We are then adding the new strings (or update existing ones if needed) in the strings.xml file of the English language in Android. To every string we add a comment for the translators about the meaning of that string and where it is used. Furthermore to ease development and easier finding strings we are ordering them in the XML based on what they are, like message, title, action, toast, label, … The English string XML file is our basis which should stay intact (in terms of formatting, structure and content). Changes on that file are also reviewed by checking the diff.

During the merge of a story into our general branches, the English string file is uploaded to Localazy. There the translation into other languages are done. Later whenever translations are ready, these files are downloaded and integrated into our repository to always have that code as part of our code base. So that we have all available translations always as part of the app bundle and then getting the correct language file installed together with the app by Google. We don’t need and actually also don’t want to have a service that updates existing strings on the fly (if internet is available), for us the big benefit of Localazy is to use is as an easier accessible hub for localization. But the actual display of the strings should still be the job of the app.

So far, we are only using Localazy on a small test app, but later on we aim to use it for our much bigger apps as well, which should follow the above mentioned approach.

I can imagine that there are maybe to many possible exceptions for translations (that are maybe incomplete), so I personally would be more then happy to have that option of keeping format & structure of the uploaded file in tact at least for the source language.

1 Like

Hello,

sorry for the delayed answer.

Additional " in the output file

We parse input files, get strings and adapt them for translators as much as possible to help them (e.g., for Android, we replace some escaped characters, etc.). However, Android’s strings XML handles, for example, whitespaces in a particular way, and we have to ensure that the resulting string is rendered 100% correctly. Therefore, we generate safeguarded version of it.

Keeping the original file and replacing strings

It’s not technically possible. Replacing texts in the original file wouldn’t work for plurals, translator adaptations, filtering untranslated phrases, format conversions, manual changes of the source key in the UI, etc. Also, it could be error-prone, and it’s way more secure to create a structure in memory and rely on the writer following standards.

Recommended workflow

I believe that your workflow where the source language file is the only source of truth is perfect. For this reason, Localazy CLI doesn’t overwrite the source language file by default (unless includeSourceLang is specified in the download section).

I would recommend keeping your English file as is (don’t overwrite it with the one from Localazy) and don’t care much about the format of other languages.