refactor: replace dynamic string composition with explicit string resources

[krvstek]

This PR refactors SettingsAboutFragment by replacing the strEnableRes and strRemoveRes methods with direct strRes calls.

Previously, the code dynamically composed strings (e.g., adding Enable... or Remove... prefixes to feature names). This approach caused significant localization issues due to varying grammar rules, genders, and word orders across different languages. By using explicit string resources, the translation process becomes much easier and the UI will look cleaner across all supported languages.

[kitadai31]

Have you checked "Delete entries from database" screen?

[krvstek]

Have you checked "Delete entries from database" screen?

I didn't touch the database string or the array itself, so it shouldn't be affected. I actually can't build and check it locally on my end right now though, could you verify if it looks fine on your side?

[kitadai31]

As I expected, the new strings have an incorrect meaning in the "Delete entries from database" dialog.

It used to look like this:

Therefore, it may be necessary to keep the dynamic string compositions for the items included in the "delete entries from database" dialog.
Other changes are fine.

[krvstek]

As I expected, the new strings have an incorrect meaning in the "Delete entries from database" dialog.

It used to look like this: Therefore, it may be necessary to keep the dynamic string compositions for the items included in the "delete entries from database" dialog. Other changes are fine.

If I knew how to compile this properly (I've read the dev docs but honestly got a bit lost there, though I'll try to figure it out and test it myself when I have some time), this issue probably wouldn't have happened.

However, I'm thinking about adding dedicated strings specifically for this dialog. I know it might lead to some duplication, but IMO it's the simplest approach and stays true to my goal of making translations easier to handle.

Moving this PR to draft until I come up with a fix in my spare time.

[kitadai31]

However, I'm thinking about adding dedicated strings specifically for this dialog. I know it might lead to some duplication, but IMO it's the simplest approach and stays true to my goal of making translations easier to handle.

I completely agree.

After reconsidering, I realized that since there are only nine strings, it wouldn't be a burden to make it dedicated strings.

I also realized that dynamically compositing these strings results in a grammatical problem.
In this dialog, any items such as "Promoted posts" should start with a capital letter, but if we do that, the "P" in "Hide Promoted posts" will be incorrectly capitalized.

So as you said, it's better to add a dedicated string for the "delete entries from database" items.

[krvstek]

fixed.

[kitadai31]

In arrays.xml, with the addition of piko_array_db_del_items, piko_array_ads_hooks is no longer used.

---

Also, is it possible to include fixes of some typo in string key in this pull request?

piko_pref_hide_detailed_posts -> piko_pref_hide_related_posts
piko_pref_db_detailed_posts -> piko_pref_db_related_posts

This originates from an old typo.
"Tweet Detail Related Tweets" was mistakenly abbreviated to "Detailed".
I fixed the text at 3cf5f9e, but I didn't fix the string key at that time.

Since changing string keys later can be a bit cumbersome, I think it's best to do it in conjunction with this major refactoring.
This also helps the translator understand the text.

[krvstek]

In arrays.xml, with the addition of piko_array_db_del_items, piko_array_ads_hooks is no longer used.

Also, is it possible to include fixes of some typo in string key in this pull request?

piko_pref_hide_detailed_posts -> piko_pref_hide_related_posts piko_pref_db_detailed_posts -> piko_pref_db_related_posts

Done.

---

@crimera @swakwork Two quick questions while I'm at it:

• I noticed piko_title_piko_integrations in the strings. It's referenced in SettingsAboutFragment.java but doesn't actually show up anywhere in the UI. Is it safe to just remove it? (I'm guessing it's a leftover from RxVxnced).
• Since my refactor already gets rid of strEnableRes and strRemoveRes, we could take it a step further and drop strRes entirely, replacing it with direct use of StringRef. What do you guys think? Is it worth doing it in this PR, or should I leave strRes alone?

[kitadai31]

My new commit was merged today, but it relies on an old dynamic string.

piko/extensions/twitter/src/main/java/app/morphe/extension/twitter/patches/logintoken/ImportExportLoginTokenPatch.java

Line 106 in d4242fc

.setTitle(StringRef.str("piko_pref_success"))

Please change this to piko_pref_import_success.
Sorry to keep asking for your help, but thank you in advance.

---

I noticed piko_title_piko_integrations in the strings. It's referenced in SettingsAboutFragment.java but doesn't actually show up anywhere in the UI. Is it safe to just remove it? (I'm guessing it's a leftover from RxVxnced).

SettingsAboutFragment.java is not from Re*anced, it's genuinely from piko settings screen.
This is a remnant of the process that copies the version number when you pressed the Integration version.
The button has been removed, but it seems they forgot to remove the internal key (preference key) to distinguish buttons.

-        if ( (key.equals(strRes("piko_pref_app_version"))) || (key.equals(strRes("piko_title_piko_patches"))) || (key.equals(strRes("piko_title_piko_integrations"))) ) {
+        if ( (key.equals(strRes("piko_pref_app_version"))) || (key.equals(strRes("piko_title_piko_patches"))) ) {

This fix is fine.
After that, you can remove piko_title_piko_integrations

we could take it a step further and drop strRes entirely, replacing it with direct use of StringRef.

I'm not a maintainer, but I think so too.

Also, since repeatedly using "StringRef" will increase the number of characters, it would be better to static import app.morphe.extension.shared.StringRef.str.
Because this file particularly uses StringRef.str many times.

[krvstek]

Please change this to piko_pref_import_success.
Sorry to keep asking for your help, but thank you in advance.

No worries at all. If there's anything else I missed, just let me know.

SettingsAboutFragment.java is not from Re*anced, it's genuinely from piko settings screen.
This is a remnant of the process that copies the version number when you pressed the Integration version.
The button has been removed, but it seems they forgot to remove the internal key (preference key) to distinguish buttons.

I meant specifically the term Integrations itself, which I assumed was a leftover from the RxVxnced project. Either way, key removed.

I'm not a maintainer, but I think so too.

Also, since repeatedly using "StringRef" will increase the number of characters, it would be better to static import app.morphe.extension.shared.StringRef.str. Because this file particularly uses StringRef.str many times.

Good idea, but let's not clutter this PR. I'll open a separate one if a maintainer gives the green light.