Answers.Body: <p>The fields that are not marked for translation are duplicated and synced between the different locales. So if you make a change in one locale, it will change it in all. This is different from saying that they are only available in one locale, which isn't possible in Craft.</p>
  
  <p>Removing/disabling them in "secondary languages" isn't possible, and doesn't make sense since there is no "primary" or "secondary" languages in Craft. You can choose to publish an entry in only your "secondary language" if you want, and when doing so you'd probably want all fields to be editable.</p>
  
  <p>But, I see your point, and I've had this dilemma myself. What I did was put the fields that weren't translatable in a separate tab (you could of course do it the opposite way, put the fields that are translatable in a separate tab). That made sense for my client, at least, but I guess it really depends on your project. :)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-27T09:37:10.727Z
Answers.Text: Separating the fields by placing them in different tabs is actually a not so bad idea, aelvan. Thanks! At least until we get a built in feature for sync indication/trigger-checkbox for each field. I already did a feature request for such a thing on g+ (see [here](https://plus.google.com/101325980081569498457/posts/627hzCGnGT7) or [here](https://plus.google.com/+LeeAston/posts/AYgszcGcb3Q)).
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-27T09:06:31.313Z
Answers.LastActivityDate: 2014-09-02T05:22:05.100Z
Answers.LastEditDate: 2014-09-02T05:22:05.100Z
Answers.UserDisplayName: André Elvan
Answers.Body: <p>Things changed with Craft 2.2:</p>
  
  <blockquote>
    <p>Translatable field labels are now marked with locale IDs to help identify which fields are translatable.</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-03T08:51:49.103Z
Answers.Text: ...and there is still space left next to that label! :) Wouldn't it be nice to have labels of all other locales sitting right there, if the field's content is still in sync to the locale you're currently editing? Maybe the fact, that the label is not just a symbol but actually names the local ID, is a little indication that such a feature is planned?!
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-09-03T08:51:10.463Z
Answers.LastActivityDate: 2014-09-03T08:51:10.463Z
Answers.UserDisplayName: carlcs
Body: <p>I'm using the localisation feature for the first time, and I'm not sure if I understand its rationale.</p>
  
  <p>On a site with entries that have multiple fields, I only have the main body text set up for translation. If I switch to the secondary language in the control panel, all fields are displayed and pre-populated with the contents of the main language (but according to my understanding, they're just pointers and not duplicated in the database). </p>
  
  <p><strong>Why are the non-translateable fields not set to disabled, marked up otherwise, or even hidden completely? Is there a way to do so?</strong></p>
  
  <p>(My concern is that my client can't identify which fields need to be translated, and hereby overwrites a non-translateable field with the secondary language.) </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-27T09:45:14.557Z
Comments.Text: The fields actually are duplicated in the database, but they are always synced and saved on every entry save. It doesn't matter in which locale you are saving the entry.
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-27T10:25:16.970Z
Comments.Text: Just to clarify the original post, a use case for "translateable" fields the way I use them: My client list might contain companies with name variants for different languages, but that are rarely used (e.g. [de:] Schweizerische Bundesbahnen = [en:] Swiss Federal Railway). I would want to leave such a field untouched, but translate the project description alongside it.
Comments.UserDisplayName: Avant la lettre
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-27T10:33:38.230Z
Comments.Text: Yep, I totally understand what you're talking about. Don't you think some kind of sync indication (comparable to the red "*" for required fields) would help in this case?
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-27T10:39:23.130Z
Comments.Text: Or the other idea I had. You actually allow such fields to be translatable, but there would be a indication of some sort, telling you if the field is still in sync across all locales. Add a checkbox to that, to trigger a new sync for the field on the next save and it'd be the perfect solution for any situation I can imagine.
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-27T10:41:49.553Z
Comments.Text: This could even make the "This field is translatable" option in the field settings obsolete!?
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-27T11:08:26.980Z
Comments.Text: I set up a site for a Client and they went nuts over this problem.
  I wrote a mail to the craftcms Team if they could flag/highlight non-translatable/translatable fields with a flag or something. Write one as well so the see its a serious request. 
  Right now it's almost impossible to determine translatable/non-translatable fields.
Comments.UserDisplayName: KSPR
Tags: <localization><control-panel><field>
Title: How to only show translated fields in an additional locale?
ThreadText: # How to only show translated fields in an additional locale?
  
  (Asked by: username_0 on 2014-08-27)
  
  I'm using the localisation feature for the first time, and I'm not sure if I understand its rationale.
  
  On a site with entries that have multiple fields, I only have the main body text set up for translation. If I switch to the secondary language in the control panel, all fields are displayed and pre-populated with the contents of the main language (but according to my understanding, they're just pointers and not duplicated in the database).
  
  **Why are the non-translateable fields not set to disabled, marked up otherwise, or even hidden completely? Is there a way to do so?**
  
  (My concern is that my client can't identify which fields need to be translated, and hereby overwrites a non-translateable field with the secondary language.)
  
  **Tags:** localization, control-panel, field
  
  > **Comments:**
  > **username_1**: The fields actually are duplicated in the database, but they are always synced and saved on every entry save. It doesn't matter in which locale you are saving the entry.  
  > **username_0**: Just to clarify the original post, a use case for "translateable" fields the way I use them: My client list might contain companies with name variants for different languages, but that are rarely used (e.g. [de:] Schweizerische Bundesbahnen = [en:] Swiss Federal Railway). I would want to leave such a field untouched, but translate the project description alongside it.  
  > **username_1**: Yep, I totally understand what you're talking about. Don't you think some kind of sync indication (comparable to the red "*" for required fields) would help in this case?  
  > **username_1**: Or the other idea I had. You actually allow such fields to be translatable, but there would be a indication of some sort, telling you if the field is still in sync across all locales. Add a checkbox to that, to trigger a new sync for the field on the next save and it'd be the perfect solution for any situation I can imagine.  
  > **username_1**: This could even make the "This field is translatable" option in the field settings obsolete!?  
  > **username_2**: I set up a site for a Client and they went nuts over this problem. I wrote a mail to the craftcms Team if they could flag/highlight non-translatable/translatable fields with a flag or something. Write one as well so the see its a serious request.  Right now it's almost impossible to determine translatable/non-translatable fields.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2014-08-27. Score: 2 | Accepted answer
  
  The fields that are not marked for translation are duplicated and synced between the different locales. So if you make a change in one locale, it will change it in all. This is different from saying that they are only available in one locale, which isn't possible in Craft.
  
  Removing/disabling them in "secondary languages" isn't possible, and doesn't make sense since there is no "primary" or "secondary" languages in Craft. You can choose to publish an entry in only your "secondary language" if you want, and when doing so you'd probably want all fields to be editable.
  
  But, I see your point, and I've had this dilemma myself. What I did was put the fields that weren't translatable in a separate tab (you could of course do it the opposite way, put the fields that are translatable in a separate tab). That made sense for my client, at least, but I guess it really depends on your project. :)
  
  > **Comments:**
  > **username_1**: Separating the fields by placing them in different tabs is actually a not so bad idea, aelvan. Thanks! At least until we get a built in feature for sync indication/trigger-checkbox for each field. I already did a feature request for such a thing on g+ (see [here](https://plus.google.com/101325980081569498457/posts/627hzCGnGT7) or [here](https://plus.google.com/+LeeAston/posts/AYgszcGcb3Q)).  
  
  ---
  
  ### Answer by username_1 on 2014-09-03. Score: 0
  
  Things changed with Craft 2.2:
  
  > Translatable field labels are now marked with locale IDs to help identify which fields are translatable.
  
  > **Comments:**
  > **username_1**: ...and there is still space left next to that label! :) Wouldn't it be nice to have labels of all other locales sitting right there, if the field's content is still in sync to the locale you're currently editing? Maybe the fact, that the label is not just a symbol but actually names the local ID, is a little indication that such a feature is planned?!  
  
  ---
  
  