On a small tangent, just above that:
36 var folderPath = StandardPaths.pictures + "/Screenshots/"
37 if (!fileUtils.exists(folderPath)) {
38 fileUtils.mkdir(folderPath)
39 }
40
41 //: Filename of a captured screenshot, e.g. "Screenshot_1"
now that thing in line 35 might be a candidate for translation actually…
I do not agree with removing localisation at all. Any self-respecting desktop OS (as well as any other mobile OS) also localises screenshot names, and anything that remains untranslated looks extremely unprofessional. If a user switches between languages and ends up with differently named files, that’s their own doing. If you switch between languages on a desktop GNU/Linux distro, you also end up with differently named folders in your home directory. In fact, the fact that Sailfish doesn’t localise folder names in the home directory is something that’s irked me from the very beginning. I can’t remember if there was ever a bug report about it.
It seems more reasonable for people who want consistent filenames but inconsistent UI translations to just run a script that renames all screenshot files with the same prefix, or no prefix at all.
I can’t remember ever having seen that until i tried Manjaro recently. And it is just an absolutely terrible experience. Sure, translate away in the GUI all you want, but that’s where it must end. Otherwise where does it stop? Translating keyboard shortcuts like in Microsoft Office? (ctrl-f no longer means Find, but Fetstil, Swedish for Bold… Search moves to ctrl-shift-s and Save As is missing in action - absolute garbage!). Or should /var, /lib, /tmp etc be translated too?
I don’t mind the files being localized, but for all that is holy; please stay away from the folders!
To be fair, that was never guaranteed.
Without going into details about collation order and things, ls -tr | tail -n -1 (oder by time, reversed) is better (but has its own problems when file timestamps change, and which of the available timestamps is the one you want. See also ls -u and ls -c).
Why is it terrible? It’s much more user-friendly for regular users, who don’t necessarily speak English and who don’t even necessarily use the Latin script. The OS knows which translated folder is used for what (e.g. “/home/user/Afbeeldingen is used for %PICTURES%”), and everything hooks into the OS so everything happens transparently and the user doesn’t experience any friction.
System directory names aren’t actual words, so there’s no point in ‘localising’ them because there’s nothing to localise. You could, but it would provide absolutely no benefit. Translated shortcuts are a different beast, that’s just bad practice. Whatever those ‘Alt-shortcuts’ are called on the other hand are unavoidable due to the nature of the translations. Common practice is to try to keep the same shortcuts as in the source string, or if that isn’t possible (because the translation doesn’t contain the source’s shortcut letter) at least keep a common shortcut across the platform.
Can we agree on, having things translated in a GUI view but not on disk? Like, “Program files” in Windows on disk but “Programas” in the Explorer for PT? Also, translating “/home” doesn’t seem to make any sense to me…
Can we agree that this is a bug report, not a feature discussion thread?
We have a whole category dedicated to “Design” and another to “Localization” on this forum - can discussions about general principles happen there please?
I was fully aware that this bug is moderately subjective, and there is no one correct answer. I simply reported an issue I ran into, and proposed a solution. One possible outcome is that nothing changes, and that would be completely acceptable. The scenario I ran into is quite uncommon after all!
Consider transfering files between devices with different locale. I would say, not so uncommon. In my case/family I have DE, PT and GB…
Thanks! I think I’ll look into creating a patch for that!
Untested, but:
diff -Naur /usr/share/lipstick-jolla-home-qt5/volumecontrol/Screenshot.qml work/b/usr/share/lipstick-jolla-home-qt5/volumecontrol/Screenshot.qml
--- /usr/share/lipstick-jolla-home-qt5/volumecontrol/Screenshot.qml 2021-11-05 19:58:51.661137361 +0100
+++ /usr/share/lipstick-jolla-home-qt5/volumecontrol/Screenshot.qml 2021-11-05 20:14:40.496900431 +0100
@@ -40,7 +40,7 @@
//: Filename of a captured screenshot, e.g. "Screenshot_1"
//% "Screenshot_%1"
- var filename = fileUtils.uniqueFileName(folderPath, qsTrId("lipstick-jolla-home-la-screenshot") + ".png")
+ var filename = fileUtils.uniqueFileName(folderPath, "Screenshot_%1" + ".png")
var filePath = folderPath + filename
shareAction.resources = [ filePath ]
As I said, not sure if fileUtils.uniqueFileName will be able to pass the parameter this way.
I’m rather sure it can, because qsTrId() returns a string, and it doesn’t use the .arg() method either. So, it must be uniqueFileName() that replaces the %1 internally.
To be fair, switching locales should not happen, unless there is a specific need for that, but I absolutely hate that I have no control over screenshot name customization and path where it is stored.
So, I would rather suggest to have settings that deal with screenshot name and location leave there localized placeholder - I for one would be interested not only how to name screenshot, but also decide if there should be used a count number or date.
//Because of error replied to different person initially
Sounds like a good approach. If you want to make one for this, there’s the #feature-requests section where you can post your idea
The PNG screenshots caused me some trouble, so I created this script which bulk-converts the files to JPG format. YMMV, as usual.
Beware, it deletes the original PNG files, so edit that bit out if you want to keep them!
Thanks for raising this @direc85. I created an internal issue for discussion, and our overall feeling is that it probably makes more sense to leave this as it is.
Your use-case, while it makes perfect sense, is rather niche, and while it’s true that most people aren’t too concerned about the filename either, they are nevertheless accessible from the UI, and not everyone will prefer the English name.
I can personally definitely see the arguments in both directions, which means explicitly making the change is harder to justify.
I have another argument for English file names. I almost never take a screenshot for any purpose other than sharing it online and there the file name in Swedish (Skärmklipp) is not very useful.
I always have to rename.
I agree - not many users are even aware of the filename, and my use case can be mitigated in plethora of ways. So, it’s understandable that this is considered “not a real issue” and thus left as-is.
Thanks for delivering the decision! Time to tackle some “real” bugs 
If you say, “implementing the translation in the UI is not high priority”, I agree. But, isn’t it standard??
Unless you go to the info page to see the full filename of the file, the translated form of “Screenshot” will be used everywhere in the Gallery app. So yes, that’s standard and independent of the filename used. You have to dig quite hard to see the actual filename from the UI.