.. _important-ace-610-academic-persons:

================================================
Important: A created profile is translated again
================================================

Description
===========

:php:`Domain\Model\Profile::getIsTranslation()` answered by comparing two
Extbase properties with each other:

..  code-block:: php

    return $this->_localizedUid !== $this->uid;

Only :php:`Persistence\Generic\Mapper\DataMapper` writes those, and only while
it hydrates a database row. A profile that was built in PHP and then persisted
never passes through it, because
:php:`Persistence\Generic\Backend::insertObject()` assigns `uid` and nothing
else. Such a profile holds a `uid` and an unset localized uid, and the strict
comparison answered "is a translation".

:php:`Profile\AbstractProfileFactory::createProfileForUser()` builds exactly
such an object: it persists the profile and announces it through
:php:`Event\AfterProfileUpdateEvent` without ever reading it back.

The method now asks the question the record answers itself. A profile that was
never persisted is not a translation of anything, and a persisted one is a
translation when the language it was read in is a translation language:

..  code-block:: php

    if ($this->_isNew()) {
        return false;
    }
    return $this->getLanguageUid() > 0;

That also settles `sys_language_uid = -1`. A record kept in all languages is
not a translation either, which the uid comparison could not express.

Impact
======

**A created profile is synchronized into its translations again.** The
:php:`Event\AfterProfileUpdateEvent` listener of EXT:academic_persons_edit
skips a profile that reports itself as a translation, because synchronization
runs from the default language record only. A profile created by
:bash:`academic:createprofiles`, the only place that creates profiles from
frontend users, was caught by that gate and never translated, no matter how
``profile.allowedLanguages`` was configured.

Profiles created before this change stay untranslated. Nothing in this version
announces an existing profile again: :bash:`academic:updateprofiles` updates
profiles without dispatching :php:`Event\AfterProfileUpdateEvent`. Translate
such a profile in the backend, into the languages listed in
``profile.allowedLanguages``.

The answer is unchanged for every profile that came out of the data mapper,
which is every profile the plugins and the backend work with. Only a profile
built in PHP is answered differently, and only one that carries a translation
language without a translation parent. Extbase cannot create such a record,
because :php:`Persistence\Generic\Backend::insertObject()` writes
`l10n_parent` as `0` on every insert.

Affected Installations
======================

Every installation that enables the translation synchronization through the
``profile.allowedLanguages`` setting of EXT:academic_persons_edit and creates
profiles with :bash:`academic:createprofiles`. Installations that leave that
setting empty see no change.

Installations calling :php:`Domain\Model\Profile::getIsTranslation()` from own
code get the corrected answer for an unpersisted and for a freshly persisted
profile as well.

.. index:: CLI, Database, Localization, PHP-API, ext:academic_persons