GNOME Bugzilla – Bug 686131
Please clarify string "initial secret passed before secret key exchange"
Last modified: 2017-05-31 19:18:47 UTC
Hallo gnome-online-accounts devs For this text string #: ../src/goaidentity/goaidentityservice.c:1167 msgid "initial secret passed before secret key exchange" could you please clarify if passed does indeed mean passed as in "passed my exam" which is what the sentence indicate, but it could also just be a short version of passed as in passing something on. Also is secret indeed secret as in "can you keep a secret" or is it something else like a key or phrase or such. Thanks in advance Kenneth
Clarification in this report is not needed and does not help other translators. Instead either a comment should be added to the code ( https://live.gnome.org/TranslationProject/DevGuidelines/Use%20comments ), or the string should be rephrased.
i can't imagine we should ever show that in the UI, so I think we probably shouldn't translate it at all. I think it means goa called the identity service the wrong way (which of course it doesn't in practice)
(In reply to Ray Strode [halfline] from comment #2) > I think it means goa called the identity service the wrong way (which of > course it doesn't in practice) How about using an assertion instead? It would make it clear that it is a programming error, and not something that's expected to happen at run-time. I thought about placing the assertion in the caller (ie. goa-daemon, not goa-identity-service), but it is tricky because GOA_IDENTITY_MANAGER_ERROR_ACCESSING_CREDENTIALS is used in at least one more place.
Created attachment 352803 [details] [review] [1st option] identity: Given a secret key, we must have a GcrSecretExchange
Comment on attachment 352803 [details] [review] [1st option] identity: Given a secret key, we must have a GcrSecretExchange i dunno, i mean should one process be able to make another abort by using its api wrong? probably we could just avoid translating the error string? and make sure it never shows up in an error dialog of course
(In reply to Ray Strode [halfline] from comment #5) > Comment on attachment 352803 [details] [review] [review] > identity: Given a secret key, we must have a GcrSecretExchange > > i dunno, i mean should one process be able to make another abort by using > its api wrong? We could use a different code for this case, and have goa-daemon assert against that. I am just looking for a way to clearly differentiate between programming errors and valid run-time failures.
I have some patches here to assert this in goa-daemon instead of goa-identity-service. Luckily, the only other use of GOA_IDENTITY_MANAGER_ERROR_ACCESSING_CREDENTIALS is never propagated outside GoaKerberosIdentityManager, so we might be able to manage without a separate error code. I'll attach them after some more testing.
Created attachment 352930 [details] [review] [2nd option] identity: Register the GOA_IDENTITY_MANAGER_ERROR domain with D-Bus
Created attachment 352931 [details] [review] [2nd option] kerberos: Register the GOA_IDENTITY_MANAGER_ERROR domain with D-Bus
Created attachment 352932 [details] [review] [2nd option] kerberos: Assert against impossible SignIn failures
Created attachment 352933 [details] [review] [2nd option] identity: Don't translate an error message that's not meant for users
looks good to me from a cursory read through. it's a bit unfortunate how manual the mapping is between error codes and dbus error strings, but it is what it is. I did some hack in g-s-d to automate the mapping: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/smartcard/gsd-smartcard-utils.c#n105 but i don't think we should that here. I say go for 2nd option, imo!
(In reply to Ray Strode [halfline] from comment #12) > looks good to me from a cursory read through. it's a bit unfortunate how > manual the mapping is between error codes and dbus error strings, but it is > what it is. > > I did some hack in g-s-d to automate the mapping: > > https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/smartcard/ > gsd-smartcard-utils.c#n105 Interesting. > but i don't think we should that here. Why not? Just curious. I do like the simplicity of the manual mapping, and it's not like the error codes change that often. But I won't mind automating it either. > I say go for 2nd option, imo! Ok. Thanks for taking a look.
(In reply to Debarshi Ray from comment #13) > Why not? Just curious. I do like the simplicity of the manual mapping, and > it's not like the error codes change that often. But I won't mind automating > it either. well up to you I guess. It struck me as a hack when I was writing it, and reading it now, dashed_string_to_studly_caps makes me shudder a bit. It does have a few advantages: 1) You can use G_DEFINE_QUARK for error quarks 2) You can drop the /* shut up gcc warning */ from class init 3) Handles new errors automatically 4) isn't done this way elsewhere (except g-s-d) It has some disadvantages: 1) crufty implementation 2) need to make sure error enums are made introspectable with glib-mkenums 3) assumes some naming consistency between quark name and enum name Probably this should get solved in glib where the implementation (crufty or not) is consolidated in one place and then mappings can get dropped everywhere in a more standard way.
(In reply to Ray Strode [halfline] from comment #14) > 4) isn't done this way elsewhere (except g-s-d) ^ i meant to add this item to the disadvantages list !