---
title: "Important: A created profile is translated again"
manual: "Academic Profiles"
version: "main"
permalink: "https://docs.typo3.org/permalink/fgtclb/academic-persons:important-ace-610-academic-persons@main"
source: "Changelog/2.4/Important-CreatedProfilesAreSynchronizedIntoTranslations.rst"
rendered: "2026-10-15T10:24:29+00:00"
---

# Important: A created profile is translated again {#important-ace-610-academic-persons}

## Description {#description}

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

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

Only `\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
`\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".

`\Profile\AbstractProfileFactory::createProfileForUser()` builds exactly
such an object: it persists the profile and announces it through
`\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:

```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 {#impact}

**A created profile is synchronized into its translations again.** The
`\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
`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: `academic:updateprofiles` updates
profiles without dispatching `\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 `\Persistence\Generic\Backend::insertObject()` writes
`l10n_parent` as `0` on every insert.

## Affected Installations {#affected-installations}

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

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