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

Default locale's field is not generated #1

Open
Chibby opened this issue Oct 25, 2016 · 3 comments
Open

Default locale's field is not generated #1

Chibby opened this issue Oct 25, 2016 · 3 comments

Comments

@Chibby
Copy link

Chibby commented Oct 25, 2016

In SiteLocaleConfig.php @ 57 you remove the default_locale from the list of locales you tell TranslatableObject to use. In my installation I never get fields for the default locale.

Why is this done?

@gavro
Copy link
Member

gavro commented Oct 25, 2016

The fields that should be translatable (according to your TranslatableObject yaml configs) end up in the "Translations" tab, but only for the locales that are not the default locale. When using TranslatableDataObject and accessing your "default locale" site and thus the default locale is initiated, SilverStripe uses the "default" fields (e.g. Title and not Title__en_US [or some other default locale]) ----> there's no need to either duplicate or move these fields to "translations" because they are considered "the default fields".

Furthermore, if these "default" fields are added (to getCMSFields), TranslatableDataObject wants to add them as "Title" and not "Title_en_US" and you'd get duplicate fields errors if you do not remove the default fields from getCMSFields yourself.

This is why I'm removing the default locale "out of the equation" (only for TranslatableDataObject, not for the allowed_locales) as it isn't relevant. The default fields are being used for that locale.

Last but not least: Seeing that these fields are not required while saving the DataObject, it would seem like a smart practise to fall back to a default value when one translatable fields is not translated in some language. This setup makes it easier for user to see what "the default value" is, e.g. the one not found in "Translations".

I feel like I'm being triple redundant with my answer. Hope it make sense..?

@Chibby
Copy link
Author

Chibby commented Oct 25, 2016

I understand the reasoning behind this. However, the functionality provided by TranslatableDataObject is altered by this, making this less friendly to implement than aforementioned module alone.

@gavro
Copy link
Member

gavro commented Oct 25, 2016

Hum, erm, I don't think so? Simple case of RT(F)M?
See: translatable-dataobject/README.md

All I have to do for example is:

    public function getCMSFields()
    {
        $fields = parent::getCMSFields();

        // add translations
        $fields->addFieldToTab(
            'Root.' . _t('Translatable.TRANSLATIONS', 'Translations'),
            $this->getTranslatableTabSet()
        );

        return $fields;
    }

Am I missing something? :)

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

No branches or pull requests

2 participants