search

getkirby / kirby

Kirby's core application folder
https://getkirby.com
Other
1.32k stars 168 forks source link

Editing title before translation file has been created causes untranslatable fields to be copied to translation file #2789

Closed fabianmichael closed 2 years ago

fabianmichael commented 4 years ago

Describe the bug
When defining field names with uppercase letters in a blueprint and setting translate: false for given field, it will be saved to the translation file, if the page title was edited before any other content has been edited for a translation.

To Reproduce

  1. Use a Kirby installation with at least 2 languages (DE and EN in this example). Include the non-translatable fields in a blueprint (pages/default.yml), e.g.:
  datestart: # <= will work as expected
    type: date
    label: Start date
    translate: false
  dateEnd: # <= will be copied to translation file
    type: date
    label: End date
    translate: false

(BTW: The error is not limited to the date field.)

  1. Create a new page with this blueprint while having the default language (DE) selected in the panel.
  2. Fill out the fields datestart and dateEnd.
  3. Make sure, that Kirby has not created a translation file default.en.txt yet. If you have not worked on the English translation before, the file should not exist.
  4. Switch to EN translation or the page.
  5. Click the page title and change it to some arbitrary value
  6. Review the newly-created translation file default.en.txt: The value of dateEnd is copied to the English translation (unexpected behavior), whereas the value of datestart is not copied (expected behavior).

Expected behavior
Fields which use the translate: false option, should never be copied to a translation file, because they are not editable from the panel any longer after that and values in the translation file are also never updated, if field values change in the primary language. This can easily lead to inconsistent content files.

Kirby Version
3.4.2

Desktop (please complete the following information):

afbora commented 4 years ago

This is known issue as #2577 #2775

fabianmichael commented 4 years ago

@afbora Thanks for pointing that out, I wasn’t aware of #2775, because it was already closed. Opened a separate ticket, because #2577 only mentions programatic changes, but not through the UI.

afbora commented 4 years ago

@fabianmichael I understand, but the source of the issue is the same. It even fixed the issue by @neildaniels and is planned for release in 3.5.0 with #2578 PR

bastianallgeier commented 2 years ago

✅