title: Gmail API - International Label Issue (C#/.NET)
body: <p>I've run into a bit of an issue while migrating mail items to a Gmail mailbox regarding label creation using multiple (human) languages. Please read the scenario before providing an answer. I apologize for the length of this post.</p>
  
  <p><strong>Scenario</strong></p>
  
  <p><em>Note: I'm aware predefined SYSTEM labels cannot be used/recreated as USER labels. I'm aware that USER labels cannot be nested under SYSTEM labels. I understand the difference between USER and SYSTEM labels. The odd looking "flat" labels generated using nested label syntax and containing SYSTEM label parts are desired (and valid.)</em></p>
  
  <p>A cache of Labels is leveraged by calling the following. This way no label that already exists is attempted to be recreated. The cache performs comparisons against the <code>Google.Apis.Gmail.v1.Data.Label.Name</code> property.</p>
  
  <pre><code>UsersResource.LabelsResource.List(string userId)
  </code></pre>
  
  <p>Labels are generated based on where the mail message is being pulled from irregardless of the system or the system's configuration.</p>
  
  <ul>
  <li>Example A: Mail message is stored on disk at "C:\Foo\Bar". Labels generated would be "Foo" and a nested label "Bar" using the syntax "Foo/Bar"</li>
  <li>Example B: Mail message is stored in an Exchange folder structure of Inbox/SomeNestedFolder. A single label is generated using the syntax "Inbox/SomeNestedFolder". This creates a single USER label not nested under the INBOX SYSTEM label. A USER defined "Inbox" label is not created because it already exists in the cache. This is desired.</li>
  <li>Example C: Mail message is stored in an Exchange folder structure of RandomTestFolder/ABC/Contacts. This creates three USER labels. First the label "RandomTestFolder. Then a nested label "ABC" under that using the syntax "RandomTestFolder/ABC". Then finally a nested label under the nested label using the syntax "RandomTestFolder/ABC/Contacts"</li>
  <li><p>Example D: Mail message is stored in an Exchange folder structure "Posta in arrivo/Test". This causes a failure while attempting to create the "Posta in arrivo" label which is Italian for inbox. </p>
  
  <p>Failure to create the label is to be expected, it is a SYSTEM label after all. What is not expected is that the product tried to create the label because it should already exist in the cache.</p></li>
  </ul>
  
  <p>After further digging this caching concept works in English environments because the list of SYSTEM label names fetched/cached by the API match the label names in the user's mailbox. However, in an Italian environment for example the API call returns label names (and IDs) as they're in an English environment. This leads the product to attempt to create labels with SYSTEM label names in the foreign language which is invalid. This occurs because the cache doesn't include the SYSTEM label names in the foreign language it has them in English. </p>
  
  <p><strong>Additional</strong></p>
  
  <p>Using the inbox SYSTEM label as an example. The API will always return the following. </p>
  
  <pre><code>{
   "id": "INBOX",
   "name": "INBOX",
   "messageListVisibility": "hide",
   "labelListVisibility": "labelShow",
   "type": "system"
  }
  </code></pre>
  
  <p><br>
  Example B shows its possible to make "flat" labels using SYSTEM label names as part of a USER label. It also shows its possible to make nested USER labels using SYSTEM label names.</p>
  
  <p><a href="https://i.stack.imgur.com/0Ct4t.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/0Ct4t.png" alt="enter image description here"></a></p>
  
  <p><br>
  The language used by the Gmail mailbox has no bearing on whether or not a SYSTEM label in another language can be created. The label "Posta in arrivo" cannot be created if the mailbox is set to English or Italian.</p>
  
  <p><strong>Question</strong></p>
  
  <p>There does not appear to be a programmatic way of dealing with this issue exposed by the API. The concept of manually mapping the strings should be avoided in favor of a solution presented by the API itself.</p>
  
  <ol>
  <li>What is the proper way to programmaticly detect and prevent attempting to create a label with a SYSTEM label name in another language? Is this a configuration issue? Is there some kind of mapping or culture setting that needs to be toggled? </li>
  </ol>