[ChromeOS] Add strings and UI placeholder for hardware-backed key.

chrome/app/generated_resources.grd

 <?xml version="1.0" encoding="UTF-8"?>
 
 <!--
 This file contains definitions of resources that will be translated for each
 locale. OS values are passed through from Python's sys.platform:
 
   win32 - Windows
   darwin - Mac
   linux2 - Linux (both Views and GTK+)
 
@@ skipping 3291 matching lines @@
       </message>
       <message name="IDS_CERT_MANAGER_EDIT_SERVER_TRUST_YES" desc="Description of option to trust the certificate, in the dialog for editing server certificate trust flags.">
         Trust the authenticity of this certificate.
       </message>
       <message name="IDS_CERT_MANAGER_EDIT_SERVER_TRUST_NO" desc="Description of option to not trust the certificate, in the dialog for editing server certificate trust flags.">
         Do not trust the authenticity of this certificate.
       </message>
       <message name="IDS_CERT_MANAGER_EDIT_CA_TRUST_BUTTON" desc="Label of button in the dialog for editing server certificate trust flags, which allows you to open the dialog for editing the trust of the issuing Certification Authority.">
         Edit Issuer Trust...
       </message>
+      <if expr="pp_ifdef('chromeos')">
+        <message name="IDS_CERT_MANAGER_IMPORT_AND_BIND_BUTTON" desc="Label for the button in the certificate manager which allows you to import certificates and bind to your device.">
+          Import and Bind to Device...

[mattm, 2011/03/01 22:26:10]

Oh, one other thought, this text is a bit long just wanted to verify whether
this doesn't make the button row too wide to fit on a chromeos screen?

[xiyuan, 2011/03/01 22:48:34]

English fits on chrome os screen and have about 100px on the right end for the
row. But other languages might have problem.

Greg, do we have a shorter name to use for the button?

+        </message>

[mattm, 2011/03/01 22:24:11]

Should be okay for now, though there is a larger question of how we want to
handle choosing the device to import to on regular Chrome. (crbug.com/70688)

[xiyuan, 2011/03/01 22:48:34]

I am not sure about the long term answer either. For R11, we are only thinking
of dealing with the keys backed by ChromeOS device.

+        <message name="IDS_CERT_MANAGER_HARDWARE_BACKED_KEY_FORMAT" desc="A format used to create label for hardware-backed keys.">
+          <ph name="KEY_NAME">$1<ex>John Doe</ex></ph> (hardware-backed)
+        </message>

[mattm, 2011/03/01 22:24:11]

I'd prefer if this wasn't hard coded, since on regular Chrome we'd like to be
able to show where a key is stored when using (possibly) multiple hardware
tokens.  Seems we might as well use the same display for both chrome and
chromeos.

I have a todo in there about using multiple columns in the cert manager so we
could have a device column, but I hadn't figured out the html for getting a
multi-column tree. (The model already has the data)

[xiyuan, 2011/03/01 22:48:34]

What format do you have in your mind?

My string comes from http://crosbug.com/12302. I guess it's because we are only
considering the ChromeOS device backed keys.

[mattm, 2011/03/02 02:58:12]

Well, I'd like to just have multiple columns, like "certificate name", "device",
etc  (like in Firefox cert manager).

In that case we wouldn't need a format string in the grd for it.  The cert
manager will already have a string for each cert about what device it's stored
in (it gets this from NSS PK11_GetTokenName function).  In the case of the
chromeos opencryptoki I'm not sure exactly what value it'll return or if you'll
have any control over that, but I guess you could hard code a special case if
you didn't like what it returns for that and there isn't a way to change it.

[xiyuan, 2011/03/02 17:42:31]

I understand that multiple columns is the desired way to display such info.

But we are planning to get this ChromeOS device backed keys in R11. And the
current plan (agreed with UI designers) is to just have minimum UI change (i.e.
one import button and this tag suffix for key name). So this format string is
most likely just for R11.

The reason I am putting together this rather empty CL is to get the strings in
before string freeze.

[mattm, 2011/03/02 23:43:12]

Sorry, think I misunderstood your previous comment.   

This is okay then, though I think it might be cleaner to have a separate format
and description string  (like "$1 ($2)" format and then a seperate
"hardware-backed" string resource that gets put in $2 for chromeos whereas
chrome could just use the token name from NSS.)

+      </if>
 
       <!-- Add Client Certificate Dialog -->
       <message name="IDS_ADD_CERT_DIALOG_ADD" desc="Title of the button that adds the certificate in the Add Client Certificate dialog">
         Add Certificate
       </message>
       <message name="IDS_ADD_CERT_ERR_INVALID_CERT" desc="Error message when the server returns an invalid client certificate after key generation">
         The server returned an invalid client certificate. Error <ph name="ERROR_number">$1<ex>207</ex></ph> (<ph name="ERROR_NAME">$2<ex>net::ERR_CERT_INVALID</ex></ph>).
       </message>
       <message name="IDS_ADD_CERT_ERR_FAILED" desc="Generic error message for a failure to add the generated certificate to the cert store/keychain">
         There was an error while trying to store the client certificate. Error <ph name="ERROR_number">$1<ex>207</ex></ph> (<ph name="ERROR_NAME">$2<ex>net::ERR_CERT_INVALID</ex></ph>).
@@ skipping 8168 matching lines @@
     </includes>
     <structures fallback_to_english="true">
       <structure name="IDD_CHROME_FRAME_FIND_DIALOG" file="cf_resources.rc" type="dialog" >
       </structure>
       <structure name="IDD_CHROME_FRAME_READY_PROMPT" file="cf_resources.rc" type="dialog" >
       </structure>
     </structures>
 
   </release>
 </grit>