Fix inconsistent wording in import/export settings

[c960657]

I made some consistency changes to the wording in the Import and export section in settings.

I think consistency in UI texts is important. If multiple terms are being used interchangably about the same concept, end-users may be confused, and it also makes translating the software more difficult. When you are new to Mastodon, there are plenty of new things to learn (instances, federation, multiple mobile apps, etc.), so there is no need to confuse matters more. In longer texts you can express yourself more freely, but UI labels should be brief and consistent.

The changes are:

• Rename “Import and export” to “Export and import” to reflect that you must first export your data, then import it (elsewhere). And reverse the order of menu items, so that Export comes first.
• When clicking on Import and export menu item to expand it, open the first submenu item (Import). Currently the second item is open which is rather odd.
• Keep Import menu item highlighted (highlights_on: :subpath) on the confirmation page shown when trying to import a list of mismatching type, e.g. importing mutes as blocks.
• Rename “Export data” to just “Export” for consistency with Import. Menu item labels should be brief, and “data” is somewhat redundant in this context. (fixed in Rename "Data export" menu item #32099)
• Reorder export items so they follow an order resembling that used in the account context menu in React app (below the top left search field).
• Consistently use the term “user” instead of ”account”. We are generally not consistent on this, but it seems “users” is the prevalent term, especially in end-user-facing UI.
• Likewise, consistently use the same terms as in the React app: “followers”, “following”, “muted users”, “blocked users”, “blocked domains” etc. [1]
• Avoid the word “list” for the individual options in the import dropdown, e.g. change “Blocking list” to “Blocked users”. This is redundant – everything here is lists.
• Change followed_accounts.csv to following.csv in the URLs and filenames of the exported CSV files so all types use the same terms as in the API, i.e. followers,following, mutes, blocks, domain_blocks (a different approach would be following the UI labels, i.e. muted_users.csvetc.).

I did not touch the header names in the CSV files. This has some BC issues, so I think this should be dealt with separately.

[1] Re “following”:
This word is a bit unusual, because it is used somewhat like a plural word meaning “followed users”. But this is what we use elsewhere. In particular, the word “follows” (plural noun) is generally not used in UI texts. Distinguishing following and followers is generally confusing, so in pages like these where space is not limited, we could use more elaborate terms, e.g “users you follow” and “users who follows you”. I like that idea.

[gunchleoc]

I have tested this and I like it. There's one change I'd make though: The export process will be used more frequently than the import process, so rather than selecting Import by default, I'd switch the 2 menu items and call the menu category "Export and import"

• Export and import
  • Export
  • Import

[c960657]

Good point. Also, from a chronological viewpoint, export comes before import. You must first export your data, before you can import it.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (1666b19) 85.00% compared to head (1ee9ae2) 85.00%.
Report is 31 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #26346   +/-   ##
=======================================
  Coverage   85.00%   85.00%           
=======================================
  Files        1058     1058           
  Lines       28281    28281           
  Branches     4538     4538           
=======================================
  Hits        24040    24040           
  Misses       3078     3078           
  Partials     1163     1163           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[mjankowski]

This needs a rebase. I think at least portions of this make sense -- I wonder if chopping it up would make review more likely?

[c960657]

I wonder if chopping it up would make review more likely?

You are probably right.

First PR: #33032