Answers.Body: <p>This turned out to be easier than expected. It's not documented in the <a href="http://buildwithcraft.com/docs/templating/filters#translate-or-t" rel="nofollow">filters section of the docs</a>, but the t() filter can take other parameters after the  tokenised variables you might want to replace in the string. Paraphrased from the source code of the globally available t() function:</p>
  
  <ul>
  <li>source: Defines which message source application component to use. Defaults to null, meaning use 'coreMessages' for messages belonging to the 'yii' category and using 'messages' for messages belonging to Craft.</li>
  <li>language: The target language. If set to null (default), craft()->getLanguage() will be used.</li>
  <li>category: The message category. Please use only word letters. Note, category 'craft' is reserved for Craft and 'yii' is reserved for the Yii framework.</li>
  </ul>
  
  <p>So, the solution was as simple as:</p>
  
  <p><code>{type|t(null, null, 'nb')}/{slug}</code> for URL format for Norwegian and</p>
  
  <p><code>{type|t(null, null, 'en')}/{slug}</code> for English.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-05T12:56:10.300Z
Answers.LastActivityDate: 2015-01-05T12:56:10.300Z
Answers.UserDisplayName: Mike Pierce
Answers.Body: <p>It works for me to use <code>{type|t}/{slug}</code> as an url format. Just make sure you make the translations before you save the entry (in the translated language). Or go back and resave the entries. The url is translated and saved at the time you save the entry, it's not updated automatically if you change the translations.</p>
  
  <p>UPDATE:<br>
  Sorry, I spoke a bit too fast. After some more testing, it seems like I was fooled by the fact that it actually translates the string to the locale you, as a user, has when editing the entry. So, I made an entry with type exhibition, created the translation to norwegian, resaved the norwegian version of the entry, and confirmed that the type had been translated. But, the next time I saved the english version, that url was translated too. </p>
  
  <p>It actually makes sense that this is the way the translate filter works. It translates based on the users current locale, not the locale of the versioned entry. Maybe it would be possible to make a new twig filter (as a plugin), that translates based on the locale of the entry, and use that filter in the url format. Not sure how you'd get the entry local passed to the filter though..</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-23T19:47:27.997Z
Answers.Text: Makes sense, but I'm still not seeing it. Could you post a sample of your translation file and maybe a shot of your section url format settings? I've done all of those steps, trying in every possible order, checked and double checked spellings and text-case and still no luck. I can't figure out what I'm doing wrong :(
Answers.UserDisplayName: Mike Pierce
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-05T12:37:56.917Z
Answers.Text: Yes, now I see what you mean, and you're right, it does make sense that it works that way. Just not for my use case :( I'll follow up if I decide to go the plugin route. Getting the locale in there should be as simple as `{type|translate_locale(locale)}/{slug}`, no?
Answers.UserDisplayName: Mike Pierce
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-12-23T15:54:04.867Z
Answers.LastActivityDate: 2014-12-24T11:55:12.793Z
Answers.LastEditDate: 2014-12-24T11:55:12.793Z
Answers.UserDisplayName: André Elvan
Body: <p>Here's my scenario.</p>
  
  <p>I have a structure section: "events". Within that I have three entry types: "events", "exhibitions", "specials".</p>
  
  <p>I would like the events to follow the following URL structure:</p>
  
  <pre><code>{type}/{slug}
  </code></pre>
  
  <p>So far no problem, since the entry type handles are defined in English. But when it comes to the Norwegian page, I want to use the Norwegian translation for each type: "arrangement", "utstilinger", "spesielle".</p>
  
  <p>So I added in the translations to my static translation file, and tried:</p>
  
  <pre><code>{type|translate}/{slug}
  </code></pre>
  
  <p>But obviously, since I'm here, I didn't have any luck. Can anyone think of a way to achieve the desired result, without resorting to adding a custom field to each entry type that would need to be filled in for every entry to use in place of <code>{type}</code>?</p>
  
Tags: <url><sections><entry-type><slug>
Title: Can I use translated properties for URL formats
ThreadText: # Can I use translated properties for URL formats
  
  (Asked by: username_0 on 2014-12-23)
  
  Here's my scenario.
  
  I have a structure section: "events". Within that I have three entry types: "events", "exhibitions", "specials".
  
  I would like the events to follow the following URL structure:
  
  ```
  {type}/{slug}
  
  ```
  
  So far no problem, since the entry type handles are defined in English. But when it comes to the Norwegian page, I want to use the Norwegian translation for each type: "arrangement", "utstilinger", "spesielle".
  
  So I added in the translations to my static translation file, and tried:
  
  ```
  {type|translate}/{slug}
  
  ```
  
  But obviously, since I'm here, I didn't have any luck. Can anyone think of a way to achieve the desired result, without resorting to adding a custom field to each entry type that would need to be filled in for every entry to use in place of `{type}`?
  
  **Tags:** url, sections, entry-type, slug
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2015-01-05. Score: 4 | Accepted answer
  
  This turned out to be easier than expected. It's not documented in the [filters section of the docs](http://buildwithcraft.com/docs/templating/filters#translate-or-t), but the t() filter can take other parameters after the tokenised variables you might want to replace in the string. Paraphrased from the source code of the globally available t() function:
  
  * source: Defines which message source application component to use. Defaults to null, meaning use 'coreMessages' for messages belonging to the 'yii' category and using 'messages' for messages belonging to Craft.
  * language: The target language. If set to null (default), craft()->getLanguage() will be used.
  * category: The message category. Please use only word letters. Note, category 'craft' is reserved for Craft and 'yii' is reserved for the Yii framework.
  
  So, the solution was as simple as:
  
  `{type|t(null, null, 'nb')}/{slug}` for URL format for Norwegian and
  
  `{type|t(null, null, 'en')}/{slug}` for English.
  
  
  ---
  
  ### Answer by username_1 on 2014-12-23. Score: 1
  
  It works for me to use `{type|t}/{slug}` as an url format. Just make sure you make the translations before you save the entry (in the translated language). Or go back and resave the entries. The url is translated and saved at the time you save the entry, it's not updated automatically if you change the translations.
  
  UPDATE:  
  Sorry, I spoke a bit too fast. After some more testing, it seems like I was fooled by the fact that it actually translates the string to the locale you, as a user, has when editing the entry. So, I made an entry with type exhibition, created the translation to norwegian, resaved the norwegian version of the entry, and confirmed that the type had been translated. But, the next time I saved the english version, that url was translated too.
  
  It actually makes sense that this is the way the translate filter works. It translates based on the users current locale, not the locale of the versioned entry. Maybe it would be possible to make a new twig filter (as a plugin), that translates based on the locale of the entry, and use that filter in the url format. Not sure how you'd get the entry local passed to the filter though..
  
  > **Comments:**
  > **username_0**: Makes sense, but I'm still not seeing it. Could you post a sample of your translation file and maybe a shot of your section url format settings? I've done all of those steps, trying in every possible order, checked and double checked spellings and text-case and still no luck. I can't figure out what I'm doing wrong :(  
  > **username_0**: Yes, now I see what you mean, and you're right, it does make sense that it works that way. Just not for my use case :( I'll follow up if I decide to go the plugin route. Getting the locale in there should be as simple as `{type|translate_locale(locale)}/{slug}`, no?  
  
  ---
  
  