Feat/save_sort_album_files

[Antonio-Riccio]

Summary

• This is a…
  • Feature addition
• Describe this change in 1-2 sentences:
  Adds two new actions to sort and move album files in track order, with an option to automatically create album-named folders.

Problem

Currently there is no built-in way in Picard to physically reorganize music files in album track order. Users have to do this manually or with external tools, which can be tedious especially when working with multiple albums.

Solution

The solution implements two new actions:

1. Sort Album Files: Allows selecting a destination folder and moves files sorted by track number
2. Sort Album Files (Auto Folder): Automatically creates a folder with the album name in a user-selected parent directory

Main features:

• Supports albums and clusters with files
• Sorting based on track positions
• Error handling and user feedback
• Dynamic action label updating with album name
• Folder name sanitization
• Updates file paths in Picard after moving

[Antonio-Riccio]

[phw]

Thanks for your contribution, but I think the behavior as implemented would be better suited as a plugin as album or cluster action. This can have the same behavior (except the context menu entry will be in the "Plugins..." section), but plugins can be more opinionated.

As a Picard functionality I think this is too specific in its assumptions about file names. Also Picard already has renaming functionality, that is flexible enough to allow generating filenames with leading track numbers and creating album folders. Yet another tool for renaming, but with an opinionated filename pattern, seems confusing.

Running this action multiple times then also seems to result in filenames always having another counter prepended.

But as I said, as a plugin this seems totally fine.

Also a general note for other PRs: Please don't update the translation files as part of feature changes. As the po files change all the time this most often leads to merge issues that are time consuming to resolve. Worst case it leads to a merge issue on the Weblate side. Hence we usually update translation files on merged changes in master and not as part of PRs.

[Antonio-Riccio]

Thank you so much for your time and clarification.