Strings that should be disabled or removed

[yarons]

Describe the bug
There are some strings in Weblate which seems as if they don't need any translation and might even damage the product if translated.

To Reproduce
Look here:
https://hosted.weblate.org/translate/did-i-take-my-meds/string-resources/he/?checksum=670e0a40af7dcb52

I'm not sure what to do and it's better to disable these kind of strings to avoid confusion, furthermore, if it doesn't need translation it can be safely removed from strings.xml and get a hardcoded replacement in the code itself.

Thanks.

[CorruptedArk]

You're right, I just forgot to set those ones to be untranslatable. And you're right about being able to hardcode most of those kinds of strings. Exporting them to resources has just been easier when I'm working on feature additions, to be honest.

[CorruptedArk]

Sorry, misclick closing it prematurely, and I just pushed a fix to master and weblate-string-translations. I'll add it to the next hotfix release tomorrow.

[yarons]

Wonderful, thank you :)

[CorruptedArk]

Also, I've tested using Hebrew strings on my device, and it appears that leaving the tags blank does not break any functionality right now. I believe it only would break functionality if I was explicitly using the tags in calling fragments. So, I'm not worried about pushing a hotfix for it today, but the changes will be in the next regular release.

[yarons]

I see, it kinda make sense that that leaving them blank won't break them, I suggest trying to translate them anyway to see if it breaks because I understood that it should be kept that way but may encounter some junior translators that will try to translate that and potentially break something.

[CorruptedArk]

I agree with your thinking and in general it could be a problem. Fortunately, it is just not a problem right now. For that reason I have now made them untranslatable, which should prevent it from becoming an issue in the future.

[xlucn]

@CorruptedArk The format strings should be disabled, too.

For example time_12, time_24 and date_format. There isn't any information in weblate to indicate that they are used as format strings. I mistakenly translated them in Chinese and now the app is basically unusable :( (one can change the system language to English as a workaround).

[CorruptedArk]

I understand where you're coming from, but I disagree that they should be disabled. Different languages will prefer different formats. However, I do agree that I should label them to prevent that from happening again. I'll make sure to incorporate a fix for those Chinese strings in the next update. Are there any other format strings that you notice broke too?

[xlucn]

I am not sure how Android deals with date and time localizations. Can't you just choose some sane default (if Android provides them) for every locale instead of let contributors translate them?

In Linux, if I run LC_TIME=zh_CN.UTF-8 date it prints in a different format from en_US locale, not just word to word translation.

Was editing on the phone, here is the output:

$ LC_TIME=zh_CN.UTF-8 date
2021年 12月 04日 星期六 02:10:05 CST
$ LC_TIME=en_US.UTF-8 date
Sat Dec  4 02:10:16 AM CST 2021

[xlucn]

From another perspective, translating format strings is error-prone. Unless there is a mechanism to check the placeholders, e.g., weblate checks if something like %1$s exists consistently in the origin string and translated string. But for Android date format like HH:mm, there is no way to ensure the translator himself knows about the format and keeps the translated format string legit for format functions. In short, this requires the translator to have some knowledge of Android's date format string to translate them.

[CorruptedArk]

You have a good point in regard to the date and time strings, and I will look into what I can do to take them off the hands of translators. Other format strings are tricky however, because they are usually regular text mixed with like one or two placeholders thrown in. If I remove those, they simply will not get translated at all.

[CorruptedArk]

I think I could do more to add checks and instructions to the other format strings though

[xlucn]

The other format strings are alright. I was mainly thinking about those rather "implicit" date format strings when I say "format strings". My phrasing was inaccurate. Those with "%1$s", etc should be quite common and self-explanatory, and platforms like weblate already checks them.

[CorruptedArk]

Alright, cool. I haven't had the time to inspect everything about Weblate, so there are details about it I'm still unfamiliar with. I figured an imperfect improvement to translations was better than none.

[CorruptedArk]

@OliverLew Did your changes to date_format break dates in Chinese? Or were the times just broken?

[CorruptedArk]

I did some tests and the date seemed broken in that it returned the exact format string back instead of a date, so I'm going to revert it back as well as the time format. I'll drop a hotfix with it today.

[xlucn]

I did some tests and the date seemed broken in that it returned the exact format string back instead of a date

Yes, that. And only the three time and date related ones I mentioned are broken in Chinese language now.