Use same logic for "no extension" case with Duplicate feature
Needs ReviewPublic

Authored by ngraham on Mon, Mar 23, 7:52 PM.

Details

Reviewers
elvisangelaccio
arojas
meven
pino
Group Reviewers
Dolphin
Summary

In the "no extension" case, we weren't separating out the path and the original filename,
breaking the feature for languages where the word "copy" would be at the beginning of the
filename, not after it (e.g. "copia de foo" in Spanish, and similar in other romance
languages). This patch fixes that by separating the original path and filename in the no
extension case as is done for the other case, which should solve the issue.

BUG: 419070
FIXED-IN: 20.04.0

Test Plan

No changes in English; should fix the issue in Spanish once new translations are done
(see https://bugs.kde.org/show_bug.cgi?id=419070 for details)

Diff Detail

Repository
R318 Dolphin
Branch
fix-duplicate-with-various-languages (branched from release/20.04)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 24120
Build 24138: arc lint + arc unit
ngraham created this revision.Mon, Mar 23, 7:52 PM
Restricted Application added a project: Dolphin. · View Herald TranscriptMon, Mar 23, 7:52 PM
Restricted Application added a subscriber: kfm-devel. · View Herald Transcript
ngraham requested review of this revision.Mon, Mar 23, 7:52 PM

This involves a string change, but given that it's to fix a bug with the feature not working correctly, I'd like to request a a string change exception from the Localization team.

Is there a reason to include the path in the translated string? Not including it would reduce the risk of translations breaking the feature (as it happens currently with Spanish in the extension case)

I thought that it was important to put all the components of a final string together in the i18n() function to prevent string puzzles. If that's not a concern here, I can remove the path from the translated part of the string.

Seems fine to me, adding @pino who could give more insights.