Field-level vs entry-level localization

Note: You must be an organization or space admin in order to set up localizations.

Field-level localization and entry-level localization are the most common ways that users set up localization within Contentful, but what is the difference between the two? Why would you use one over the other? This article will help demystify these localization strategies so you can choose the ideal approach for your project.

Need an introduction to localization and translation in Contentful? See our article about it here.

Content type-level and space-level localization are also possible. While they offer more flexibility than either field-level or entry-level localization, they also require much more overhead and maintenance. As a result, they exceed the scope of this article, but you can find out more about those approaches in our developer documentation here.

Field-level localization

Do you frequently publish content in multiple languages at the same time, such as a bi-lingual blog? Then you’ll find field-level localization is probably the best fit for you. Field-level localization works best when your goal is to publish your translated content at the same time as your default language content. Organization admins can configure which fields on which content types support localization. For example, you may want the page title to be localized, but have the same value in the event date field for all translations of an event page. So, if you have an event happening on Halloween, the event-date for all translations will be October 31st. Field-level localization also has the added benefit of letting you see multiple locales at once on the same screen, which isn’t possible with entry-level localization.

Viewing multiple translations at once with field-level localization

Entry-level localization

If you need to publish your translations at different times, entry-level localization is likely a better match for your workflow. With entry-level localization, you create a content type that serves as the container for your localized content. For example, if you have an article content type, you could call the container content type "Article - Global". That content type would only need two fields:

• Title (which would be used within your space in order to find this content later)

• A multi-reference field that will contain the localized articles

You would then create a separate content type that you would use for the localized content. This content type would then be referenced in the multi-reference field of  the container content type ("Article - Global" in this example). With this workflow, you can publish your page asynchronously as each translation becomes ready. This way, your content editors working in English don’t have to wait for their German counterparts to finish their translations before publishing their work, for example.

Article with only one translation published

Article with two translations published

With entry-level localization, the main drawback is governance.  Unlike field-level localization, you cannot restrict a user to just one locale.  This means a user can create entries in any of the locales that you have configured. However, you can mitigate this by preventing users from attaching those articles by setting up specific content permissions.