Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Id, language pid and language column not translated #61

Merged
merged 1 commit into from
Jan 20, 2020

Conversation

dmolineus
Copy link
Contributor

@dmolineus dmolineus commented Jan 16, 2020

Right now the id, langPid and langColumn doesn't get translated by default which causes several issues:

  • It's not possible to determinate the language from an loaded model
  • It's not possible to determinate the real id of an loaded model
  • Saving a loaded model would override the fallback language

So this pull request always handles such columns as translated columns.

Furthermore it addresses an issue in the getAlias method which uses the actual id and not getLanguageId().

@richardhj richardhj requested a review from qzminski January 16, 2020 16:00
@@ -107,8 +108,14 @@ public function buildQueryBuilderForFind($language)
{
$this->qb->resetQueryParts();

// Always translate system columns
$systemColumns = ['id', $this->langColumnName, $this->pidColumnName];
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use the hardcoded id column here because it's already hardcoded, f.e. https://github.com/terminal42/contao-DC_Multilingual/pull/61/files#diff-56e9eeb0a83d5059b7bccbea1878371bR133

@qzminski
Copy link
Member

Thank you for this pull request!

I think this might be a BC break as I am pretty sure there are some extensions which rely on those column values, so merging it in the current state is not possible IMO. We would have to get rid of id and pidColumn from columns that will be translated.

It's not possible to determinate the language from an loaded model

That could be an issue indeed and we should fetch language from the model 👍🏻

It's not possible to determinate the real id of an loaded model

I think this could be done using Multilingual::getLanguageId() no?

Saving a loaded model would override the fallback language

Isn't a multilingual model always prevented from saving?

$model->preventSaving(false);

The current concept of a multilingual model is that it is not a real-data model but is a combination of the fallback record + language record, so by any means it should not be saved. If you would like to update the language record itself, you would have to fetch it using findByPk($model->getLanguageId()) and then save it.

/cc @aschempp @Toflar

@dmolineus
Copy link
Contributor Author

I think this might be a BC break as I am pretty sure there are some extensions which rely on those column values, so merging it in the current state is not possible IMO. We would have to get rid of id and pidColumn from columns that will be translated.

It depends on what is the intended purpose/design of the model, but I'd understand if you see it as a BC break. As a workaround I marked this fields as translatable.

It's not possible to determinate the real id of an loaded model

I think this could be done using Multilingual::getLanguageId() no?

No, it's not and that's why I think the current implementation is broken.

Multilingual::getLanguageId() would get the language pid if it's not 0, but within the current implementation it is always 0. The columns id, langPid and language always have the value of the fallback version of the model.

public function getLanguageId()
{
$pidColumn = static::getPidColumn();
if ($this->{$pidColumn} > 0) {
return $this->{$pidColumn};
}
return $this->id;
}

Isn't a multilingual model always prevented from saving?

Sorry, you're right. Missed that.

@qzminski qzminski changed the base branch from master to hotfix/4.0.1 January 20, 2020 11:28
@qzminski qzminski merged commit a115793 into terminal42:hotfix/4.0.1 Jan 20, 2020
@qzminski
Copy link
Member

After a quick internal discussion we are good to merge it into 4.0.1. Thank you David!

@dmolineus
Copy link
Contributor Author

Thanks your the quick release.

@aschempp
Copy link
Member

aschempp commented Jan 7, 2021

Unfortunately, @qzminski was right with the initial assumption that this would be a BC break, see #69

I can't remember being part of that "internal discussion", any idea what that was about?

@qzminski
Copy link
Member

qzminski commented Jan 7, 2021

Well, we probably discussed it on Skype, but as that was one year ago I am unable to find any relevant information. Probably I just sent this link and everyone agreed it should be merged 🤷🏻‍♂️

I think we should ignore that previous discussion anyway and approach this again with a fresh look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants