Have you checked "Delete entries from database" screen?

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?

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.

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.

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.

fixed.

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.

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?

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

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.

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.

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!

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

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.

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.

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

Hey @swakwork, I see Twitter is getting some updates again in recent releases.

Since this is active, could we look into merging this refactor soon? I want to get it synced before the new changes create major conflicts.

Let me know if anything specific needs to be adapted on my end regarding the Crowdin migration you mentioned earlier.

Hey @swakwork, I see Twitter is getting some updates again in recent releases.

Since this is active, could we look into merging this refactor soon? I want to get it synced before the new changes create major conflicts.

Will plan to include on the next Twitter release.

Let me know if anything specific needs to be adapted on my end regarding the Crowdin migration you mentioned earlier.

I'm don't know much about Crowdin. Do we need to include the new base keys to the project or will the translators themselves be adding them.

I'm don't know much about Crowdin. Do we need to include the new base keys to the project or will the translators themselves be adding them.

From what I can see, this repo uses the exact same script as Morphe (Crowdin push/pull). So if there's a change in the strings, the push workflow replaces the source files, and the strings update automatically.

Someone correct me if I'm wrong.

@swakwork

Will plan to include on the next Twitter release.

Then, could you merge this right now?

So the new strings will be reflected in Crowdin automatically, and we can get started on the translation.

Also, it would be helpful if you could make a brief announcement in the Telegram group Updates section.
Like:

For translation contributors: There have been significant changes to the Twitter strings. Dynamic string composition such as "Remove %s" and "Export %s" has been removed, and all strings can now be translated as independent strings. Many existing translations need correction. Please check on Crowdin.

Will plan to include on the next Twitter release.

Then, could you merge this right now?

Well, by Twitter release I meant Piko update

So the new strings will be reflected in Crowdin automatically, and we can get started on the translation.

I dont mind merging it, now but the thing is I'm occupied, so I may not be able to support or do emergency release if needed.

Anyways let me merge it, I personally have not tested it, so if something goes wrong.... may god be with us 😌🙏

Anyways let me merge it, I personally have not tested it, so if something goes wrong.... may god be with us 😌🙏

Thanks! No need to worry, this PR only changes strings and I've already personally tested it, so nothing should break.

Thanks! No need to worry, this PR only changes strings and I've already personally tested it, so nothing should break.

Big thanks for the PR and so sorry for the delay

Oh wait, did you run release workflow seriously?
I didn't mean that 😭
What I meant was to merge this PR into the dev branch right now so that the new strings is pushed to Crowdin, but not release the dev patches it yet 😭
This gave translators time to work on their translations before the "next Twitter release"

Well, what's done is done

In my opinion, it would be better to remove the release, but of course it's up to you
EDITED: nvm I just saw your announcement in Tg. I think there is no need to remove.

Anyway, I'm sorry for involving you in this troublesome matter when your time is occupied 😥