In the message catalogue, pot file, for dnf, there is the string "Size". The Swedish translation of this word is a bit longer, "Storlek", 7 letters.
The string is used in two contexts: as a header entry in the summary of a transaction to be performed, and as one of the labels to the left in the info listing of a package.
In the info listing, there is no problem to use the correct word in the translation. In the transaction summary, however, the line overflows if the translation is longer than 6 letters, resulting in an ugly printout.
To work around the problem, I have translated the string with "Storlk", omitting the "e" at the end. It looks a bit silly, but is understandable. When used in the header of a transaction summary, it is rather obvious why the workd is abbreviated. One could even consider abbreviating it to "Storl" to fit more exactly over the actual column, leaving the expected space at the end.
In the info listing, it looks plain wrong to have the word abbreviated. But there isn't any way to fix this without breaking the other instance.
I'm not sure what the best way to fix this is. In a C program, one could use the context version of the gettext function to distinguish the two cases, but that isn't available in Python as far as I know. Still, it is a misfeature.
I think it is easy to fix now following the same pattern as in bug 1305340. But I can see more strings which should be split into long and short forms:
"Arch" (even in English there could be "Architecture")
"Repo" (oh, there is a word "Repository" already in dnf)
"From repo" ("From repository"?)
Anything else? "Name", "Version", "Release", "URL", "Description", "ID"? Maybe split all those which appear in more than one place and potentially may need a long and short version, and eventually leave the decision to the translators whether they want to provide two versions or not?
Splitting things is typically a good thing. When the translation is the same it is a little bit of extra work, true. But when the translation for different uses of the same word differ, it could be the difference between a correct and a broken translation. The extra work in the first situation is well worth it.
libcomps-0.1.10-2.fc29 libdnf-0.26.0-1.fc29 dnf-plugins-core-4.0.4-1.fc29 dnf-plugins-extras-4.0.2-1.fc29 dnf-4.1.0-1.fc29 librepo-1.9.4-1.fc29 createrepo_c-0.12.1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1fccede810
createrepo_c-0.12.1-1.fc29, dnf-4.1.0-1.fc29, dnf-plugins-core-4.0.4-1.fc29, dnf-plugins-extras-4.0.2-1.fc29, libcomps-0.1.10-2.fc29, libdnf-0.26.0-1.fc29, librepo-1.9.4-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1fccede810
createrepo_c-0.12.1-1.fc29, dnf-4.1.0-1.fc29, dnf-plugins-core-4.0.4-1.fc29, dnf-plugins-extras-4.0.2-1.fc29, libcomps-0.1.10-2.fc29, libdnf-0.26.0-1.fc29, librepo-1.9.4-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.