Follow up for bug 1309188 to remove netmonitor.css workaround - overwrite tree-view cell colon. We should remove ":" l10n strings from netmonitor.properties which used in security panel. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1309188#c11
@Eitan: are there any recommendations how to deal with colon characters in strings? Is it ok to keep them in the string? Honza
I would ask a localization expert!
Flags: needinfo?(eitan) → needinfo?(l10n)
I'd need a pointer to the actual localized string in question, and where it's used. I didn't find anything l10n-related ad-hoc in bug 1309188.
See attachment at https://bug1309188.bmoattachments.org/attachment.cgi?id=8815268. In Security Panel new UI, every label along with a colon `:` (ex: Connection:, Protocol version:...etc)
I'm still having a hard time understanding what the question is. The old and new UI look exactly the same in the screenshot. https://hg.mozilla.org/releases/mozilla-aurora/file/default/devtools/client/locales/en-US/netmonitor.properties#l589 Are you asking to remove all ':' from these strings? The only way do it would be to use new string IDs for all of them, and ask localizers to "re-translate" them. As you can understand, that's far from ideal. Weren't these strings added very recently (bug 1308503)?
(In reply to Francesco Lodolo [:flod] from comment #5) > Are you asking to remove all ':' from these strings? The only way do it > would be to use new string IDs for all of them, and ask localizers to > "re-translate" them. As you can understand, that's far from ideal. Question: Are there any reasons why we have to append a colon after these strings  ? Our use case is to display security information as you saw in attachment. If the influence is minor, we'd like to remove the colon from netmonitor.properties and then create the colon in a separate element in order to fit into our component structure without hack.  https://hg.mozilla.org/releases/mozilla-aurora/file/default/devtools/client/locales/en-US/netmonitor.properties#l589
(In reply to Ricky Chien [:rickychien] from comment #6) > Are there any reasons why we have to append a colon after these strings ? How would you manage cases where you need a specific locale-dependent character before the colon? Japanese and French are two good examples. Can you explain what problem you're trying to solve by splitting the colon? Please bear in mind that we don't work on devtools, so we might a lot of background for this kind of requests. P.S. no point in NI pike at each question
The problem we are solving is related to strings containing a colon character at the end. It's a general question about how to properly deal with such strings. Here are a few examples of strings we have: netmonitor.security.protocolVersion=Protocol version: netmonitor.security.cipherSuite=Cipher suite: netmonitor.security.hsts=HTTP Strict Transport Security: netmonitor.security.hpkp=Public Key Pinning: You can notice that every string has a colon character at the end. The question is whether it's recommended to keep the colon character as part of the string and allow translators to translate even the colon. It looks like this can be useful for languages like Chinese where different colon character can be used. The other option is to remove the colon char from the string and append it programmatically so, translators don't have to translate the colon in every string again and again. In order to support translation of the colon (is it actually needed?), should we have an extra translatable string for it? Something like as follow: netmonitor.security.colon=: What is the recommended approach here? Thanks, Honza
(In reply to Jan Honza Odvarko [:Honza] from comment #8) > What is the recommended approach here? Thanks, a lot clearer now. The recommended approach is to have the colon as part of the string, as it is now, so that localizers can make the best choice for their languages. To split, you would still need the colon as a localizable character, since some languages don't use that (e.g. Armenian uses '.'). And you would still be imposing a structure by adding the colon: for example, French would have to end each of the labels with a non breaking space, because you need one before punctuation. That's easy to break, and doesn't work well with translation memories either.
(In reply to Francesco Lodolo [:flod] from comment #9) > (In reply to Jan Honza Odvarko [:Honza] from comment #8) > > What is the recommended approach here? > > Thanks, a lot clearer now. > > The recommended approach is to have the colon as part of the string, as it > is now, so that localizers can make the best choice for their languages. Great, thanks! So, I am closing this report. Honza
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
No longer blocks: 1307743
You need to log in before you can comment on or make changes to this bug.