Plugin - Content Internalization

[OrestTs]

Hello everyone, in Strapi Road Map found this Feature "Plugin - Content Internalization". And I got question and when it will be developed? Maybe someone already started?

Expected behavior:

Translate the content of your API in any language, from the admin panel.

[maru3l]

I'm actually working on something. The way a see it's to make a entry of the same content type for each language and link them together with a relation.

[OrestTs]

@maru3l can I take a look? some exaples etc.? it will be great if you can :)

[maru3l]

The test I've made is only to create a relation and a select field in the entry. I use the select to select the language and the relation to relate the article. It's working perfectly.

What I'm working on, it's to make a plugin who automatically create they's field, make it invisible and add a widget in the creation page to make the link between the post easier.

[OrestTs]

Maybe Strapi Team can tell us ,when it will be developed? ;)

[lauriejim]

There is no date for this feature. We will not work on it for next months.

[Aurelsicoko]

The design is almost ready on our side, this is not planned in the public roadmap but we have it in mind. We are moving fast and we could imagine that we will start working on it at the end of the summer (end of August).

@maru3l Feel free to contact me if you want more insights and specifications about the feature 👍

[maru3l]

@Aurelsicoko I've already spoke to Pierre a weeks ago to explain my idea, but I'm still open to get more information or giving help to make this feature append. It's a must have for my client and I can't make them use Strapi if this feature is not available.

The only thing blocking me right now it's because I have to edit the content-manager package for adding my widget. But I know it's not a good adea to write directly in it if someone change the package after.

[joonashak]

I'm currently developing a bilingual website using Strapi as my backend. I'm using a similar approach, namely storing two entries, one for each language and linking them with a one-to-one relation. However, the content type builder forces me to define two relational fields when linking a Page item to another Page item. I didn't want to file a bug report straight away, but currently I'm thinking that this is incorrect behaviour. As one-to-one links one and only one document to another, wouldn't it be simpler and more elegant to have only one field?

Example:

Say we have a Page document called A in English and want to create a corresponding document B in Finnish.

Expected behaviour:

Create a one-to-one relation that links two Page entries. Only one field should suffice for this type of linking, thus it is expected that one would be able to create the relation and express it in a single field called translation (in the example case). A.translation would then contain B and B.translation would contain A.

Current behaviour:

Content type builder forces me to create two fields with unique names when creating the Page-to-Page relation. E.g., I could have fields translation and translationLink, both of which express the exact same relation. The result is that unnecessary code is required to check both fields where one would be enough (or have the user or another piece of code populate both "directions", i.e., all four fields).

Is my reasoning correct, and if so, should I file a separate bug report or feature request?

[MartinMuzatko]

To point out the elephant in the room: Did somebody try the paid i18n plugin?
Does it do what it claims? 300 $ for a plugin sounds like a lot, especially if you do hobby-websites.
There is an item on the roadmap marked as not done and there is the plugin in the marketplace.
I personally think it is a must for a good CMF to have open source I18n solution.
But maybe the two plugins do separate things.

To me it is a bit unclear what the difference is. From the description, it looks like the plugin does most of the translation automatically:

Translate your data and import them instantly with the API or through the dashboard.

In that case: I wouldn't need that. I would be fine translating on my own. Also it would fit into Strapis philosophy to only make premium plugins for third party integrations such as stripe, paypal etc.

[Aurelsicoko]

@MartinMuzatko The i18n plugin is available on the marketplace but you won't be charged for it because it's not developed yet. It helps us to know if the plugin is requested or not.

As I already said, we can't offer all the features for free. We have to find a way to make the OSS sustainable. If we offer everything for free, the project is going in the wrong direction and it'll certainly die in a few years. A lot of enterprises, web-agencies or startups are using Strapi and they are able to pay for some features. We're trying to do our best to build a smart business model. As an OSS it's complicated for us to charge based on the usage (requests/s for example) so we have an approach based on the features offered for now. Everything can change, we're listening to the feedback to find the perfect match between the community version and the paid version of Strapi.

[MartinMuzatko]

@Aurelsicoko I'm not saying charging for plugins is wrong. I just wanted to know what the exact difference is, because there is the (not yet) paid version which claims to "translate everything instantly" which is a bit unclear. it sounds like it would do like the community plugin for i18n. So you can imagine there is some confusion. Thanks anyway, I'm sure you will find a good way to monetize strapi :) just keep your nice community and your healthy way of getting in touch with your userbase.