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.

[krvstek]

Hey @swakwork, just a quick ping since this PR has been hanging around for a few months. Could you take a look and let me know if the code looks good to you?
​
I'd like to prepare some more PRs for the project, but the next one I'm working on directly depends on these changes getting merged first. Let me know if you need me to adjust anything!

[swakwork]

idk, for now I'm planning not to touch anything related to Twitter. Moreover, strings now come from Crowdln, so we might need to update there as well. So far now I'm not gonna pause it.
Will let you know based on the future of Twitter

[krvstek]

idk, for now I'm planning not to touch anything related to Twitter. Moreover, strings now come from Crowdln, so we might need to update there as well. So far now I'm not gonna pause it. Will let you know based on the future of Twitter

Makes total sense, especially with the recent changes making things so unpredictable.

Just a quick note regarding Crowdin, though: as far as I know, any string modifications pushed here should automatically sync with Crowdin via the GitHub workflow, so it shouldn't require any manual updating on our end.

[kitadai31]

One thing to be aware of when merging this pull request is that after it is merged, the strings will be incomplete in that language until the translation is updated.
For example, the "Hide promoted posts" setting will temporarily display as "Promoted posts" until the translation in that language is corrected.
This becomes more problematic for languages ​​where there are no active translators.

Therefore, I propose the following merge strategy:

1. Merge the latest Crowdin translations
2. Release v3.3.0 stable
3. Merge this PR immediately after 2.

This gives translators time to update their strings before Swak releases v3.4.0-dev.1.
(Because this pull request is refactor:, no new pre-release will be generated.
On the other hand, when this commit is pushed to the dev branch, the strings on Crowdin will automatically be updated. In other words, the translators can immediately begin updating the string.)

Furthermore, because stable versions are released less frequently, there is ample time before the next stable version (v3.4.0) is released. This reduces the likelihood of stable users encountering incomplete strings.

[krvstek]

Therefore, I propose the following merge strategy:

1. Merge the latest Crowdin translations
2. Release v3.3.0 stable
3. Merge this PR immediately after 2.

That's a very good strategy ^^
Sounds like a solid plan to keep the translations intact for stable users.