#168 Can't locate string in the sources

Open
opened 2 weeks ago by jstolarek · 4 comments

When I mount an encrypted drive Konqueror prompts me to input password to decrypt it. The window title says “Decrypt Storage Device” but I just can’t locate it in the source code with greping. Where does that string come from? I’d like to translate it.

When I mount an encrypted drive Konqueror prompts me to input password to decrypt it. The window title says "Decrypt Storage Device" but I just can't locate it in the source code with greping. Where does that string come from? I'd like to translate it.
37 KiB
SlavekB commented 2 weeks ago
Owner

There seem to be two problems for this string:

  1. There is not used i18n() => the string is hardcoded and therefore not part of the POT/PO files – see tdeioslave/media/mediamanager/dialog.cpp and tdeioslave/media/mounthelper/dialog.cpp
  2. The string is no longer part of the master branch, but only r14.0.x, because in the master branch it is now called Unlock Storage Device => therefore this string will not be available on the TWTW and it will be necessary to make a pull request in the TGW once it is part of the POT/PO for the r14.0.x branch.
    Maybe we could change the string also in r14.0.x branch, because unlock is more appropriate for the operation that is being performed.
There seem to be two problems for this string: 1. There is not used `i18n()` => the string is hardcoded and therefore not part of the POT/PO files – see [tdeioslave/media/mediamanager/dialog.cpp](src/branch/r14.0.x/tdeioslave/media/mediamanager/dialog.cpp#L26) and [tdeioslave/media/mounthelper/dialog.cpp](src/branch/r14.0.x/tdeioslave/media/mounthelper/dialog.cpp#L26) 2. The string is no longer part of the master branch, but only r14.0.x, because in the master branch it is now called *Unlock Storage Device* => therefore this string will not be available on the TWTW and it will be necessary to make a pull request in the TGW once it is part of the POT/PO for the r14.0.x branch.<br/>Maybe we could change the string also in r14.0.x branch, because *unlock* is more appropriate for the operation that is being performed.
MicheleC commented 2 weeks ago
Owner

In R14.0.x branch, the lock/unlock operations are referred to as encrypted/decrypted and the status of a disk would be shown as such. changing the string to Unlock may be confusing to the users. The icon file names are also namned accordingly, so we should probably not modify the string in my opinion.

If we want to translate the string, we should probably do it through a PR here. So in my opinion we should not port the change done in PR #169 in R14.0.x

In R14.0.x branch, the lock/unlock operations are referred to as encrypted/decrypted and the status of a disk would be shown as such. changing the string to Unlock may be confusing to the users. The icon file names are also namned accordingly, so we should probably not modify the string in my opinion. If we want to translate the string, we should probably do it through a PR here. So in my opinion we should not port the change done in PR #169 in R14.0.x
SlavekB commented 2 weeks ago
Owner

In R14.0.x branch, the lock/unlock operations are referred to as encrypted/decrypted and the status of a disk would be shown as such. changing the string to Unlock may be confusing to the users. The icon file names are also namned accordingly, so we should probably not modify the string in my opinion.

If we want to translate the string, we should probably do it through a PR here. So in my opinion we should not port the change done in PR #169 in R14.0.x

In essence, the current encrypt / decrypt naming in R14.0.x is confusing to the users because the encrypted partition is actually locked / unlocked. So it seems more appropriate to fix also other strings that use encrypt / decrypt, even though the methods in the R14.0.x branch are called encrypt / decrypt.

> In R14.0.x branch, the lock/unlock operations are referred to as encrypted/decrypted and the status of a disk would be shown as such. changing the string to Unlock may be confusing to the users. The icon file names are also namned accordingly, so we should probably not modify the string in my opinion. > > If we want to translate the string, we should probably do it through a PR here. So in my opinion we should not port the change done in PR #169 in R14.0.x In essence, the current encrypt / decrypt naming in R14.0.x is confusing to the users because the encrypted partition is actually locked / unlocked. So it seems more appropriate to *fix* also other strings that use encrypt / decrypt, even though the methods in the R14.0.x branch are called encrypt / decrypt.
MicheleC commented 2 weeks ago
Owner

yes, as we discussed in IRC, that is ok.

What should we do about this issue? Close given #169 solved the orinigal problem?

yes, as we discussed in IRC, that is ok. What should we do about this issue? Close given #169 solved the orinigal problem?
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Loading…
There is no content yet.