Screenshot filenames are localized

REPRODUCIBILITY: 100%
BUILD ID: 4.3 (This has most likely existed before)
HARDWARE: X10II
UI LANGUAGE: Finnish / English
REGRESSION: Unknown

DESCRIPTION:

Screenshot filenames are localized, which causes them to be ordered not by date anymore, making ls -1 | tail 1 not guaranteed to return the latest screenshot anymore, and just browsing the files with computer using media share also makes them appear in non-chronological order, which can be confusing.

PRECONDITIONS:

Know two supported languages well enough to use the languages on the device :slight_smile:

STEPS TO REPRODUCE:

  1. Use e.g. English language
  2. Take a screenshot
  3. The filename is Screenshot_20211105_001.png
  4. Switch to e.g. Finnish and reboot
  5. Take a screenshot

EXPECTED RESULT:

The filename is Screenshot_20211105_002.png

ACTUAL RESULT:

The filename is Näyttökuva_20211105_001.png, and not _002.png as one would expect.

ADDITIONAL INFORMATION:

Rationale: Filenames are not important when accessing the images by, say, Gallery. When the files are accessed by filename, for example by using Terminal, the user assumes consistency in filenames; aka. the filename ordering should follow the time. Changing the locale breaks this assumption, causing confusion. Sorting files by date is also an option, but history has taught me (mostly on Windows, but still) that file timestamps can not be blindly trusted.

Hence I propose removing localisation in this specific use case, either by stopping translating the string (or by dropping the prefix):

  • Pictures taken with Camera are not prefixed with e.g. Camera_ either
  • Providing localized screenshot names doesn’t really add anything to a user who is technical enough to “care about the filenames”
  • Having locale-dependent filenames make filenames non-predictable
  • The _001.png numbering per day scheme can break
  • Some languages, e.g. Finnish, use non-us-ascii characters that may cause issues (Näyttökuva)
5 Likes

I think the cause is this:

/usr/share/lipstick-jolla-home-qt5/volumecontrol/Screenshot.qml

 40
 41         //: Filename of a captured screenshot, e.g. "Screenshot_1"
 42         //% "Screenshot_%1"
 43         var filename = fileUtils.uniqueFileName(folderPath, qsTrId("lipstick-jolla-home-la-screenshot") + ".png")
 44         var filePath = folderPath + filename
 45
 46         shareAction.resources = [ filePath ]
 47
 48         var result = Lipstick.takeScreenshot(filePath)

… a patch to that should be quite trivial todo, BUT I don’t know how to do a fixed English string with a parameter…

This might even show different results depending on what the translator chose to do. Languages which just use “Screenshot” as an anglicism will not show the problem, others will.

Therefore, maybe making the source string non-translatable might be another solution.

@jahonen @sledges, opinions?

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.

1 Like

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!

1 Like

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.

1 Like

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…

1 Like

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