Suggested improvements to multi-lingual document data and management

Hi, I'm about to implement a few features such as Most read blogs and would need to collect readership stats. I understand that this is not something Prismic offers, but I'm sure that plenty of people have had the same requirement and before I reinvent the wheel, I was wondering if there are any draft concepts or packages for Javascript/React/Laravel that do already that and more. Ideally I would not just like to know if someone opened a blog page, but get an indication if the person actually read it in full or not. I would also be interested what your concept looked like to support multi-language blogs.

Please let me know how you solved this if you have done this already.


Hey @peter2,

I know there are a lot of great options out there for analytics, like Netlify Analytics and Simple Analytics. I only have experience with Google Analytics, which is what we use on the Prismic Docs. It's free and very powerful, including data like user navigation, time on page, session duration. If you combine it with Google Tag Manager, you can program more advanced reporting, like whether a user scrolled to the bottom of a page.

For mutli-lang with React, the most important part is how you construct your API query. In your repository, you can have parallel translations of your content in multiple languages. Then, when you query the API, you simply the language you want (en-us, fr-fr, etc). Often, this would be based on the route (/en-us/hello-world). But you could also do it in the state of your app. Here are the docs for querying by language:

Also, here's how another user did it:

Let me know if you have any other questions.


Hi Sam,

I'm using Google Analytics for my own reporting, but I am planning to get away from it as more and more users opt out on ePD and GDPR related cookies and data usage. I can also not expose the api keys of GA directly in the frontend for security reasons and would need to have this done by the backend which makes me wonder if there is no better integrated approach.

As for the support of multi-languages. The link you sent is a very specific use case which to be honest i don't think many people have - Beyond the standard lang option, they load all languages for what it looks like the sole purpose of looping through them in the banner. But that isn't a concern I have. When it comes to readership I want to show the top blogs in the currently set language based on readerships in any language. I use canoncial links to combine the readership of different languages to my defined main language, but this basically means that the reports i can draw from GA always shows me the top blogs with urls of the main language. I would then need to query those with the CMS to get the urls in the currently set language which doesn't sound like an effective way.

Best Regards,

I'm keen to hear if anyone else how they implemented a solution with or without GA (or similar).


Hey Peter,

Please let me know if you find a better approach. I would love to know what folks are using for this.

I don't think I completely understand your challenge with multi-lang. First of all, what are you using for routing?

Generally, we encourage users to include the language in the route, like /en-us/hello-world and /fr-fr/bonjour-a-tous. Your homepage might be / in English and /fr-fr in French. When you load /, you will query the list of posts in English. When you load /fr-fr, you will use the route parameter to query the list of posts in fr-fr.


The challenge has nothing to do with routing. That works completely fine. It's to do with that Prismic has a very basic support for multi-lingual content.

  • This starts with that it's difficult to see which content exists in which languages at a glance in the UI (I raised a ticket a while ago and sent screenshots of a competitor that I thought does it very well)
  • and includes that to get all Meta data for a page (in particular links) I need to send sub-queries for all alternate-language documents
  • images can only have one alt text. Alt text should however always be in the language of the document. There is a work-around by maintaining the alt text of images in the documents, but it's just a work-around, not a solution.
  • to finally - and that's the difficulty in this case - I need to run one query to get the list of top most read docs (which will be urls in the main language), then i need to run a query for all documents to get the alternate_language object to be able to run another query for the same docs but in the language that the user wants. I'm now supporting those efforts by using my backend, but it would have helped if there is a generic UID across the languages of one document. So, a query of 'ABC' in en-gb would work in the same way as a query of 'ABC' as the UID with language fr-fr. That would reduce the number of api calls dramatically.

Hi @peter2,

There's a lot of good information here. I'm going to take a closer look on Monday and take some time to respond. Have a good weekend!


Hi Sam,

Those are just summaries - happy to give you more information if needed.


Hey @peter2,

One question of clarification:

When you say images can only have one alt text, this is not the expected behavior. You should be able to define separate alt text in each locale. Could you explain more the issue that you're having here?


Sure, I actually gave details in here. Basically, you really want to manage alt text in multiple languages directly on the media, not in the document. Currently there is only one alt text field in the media which is pulled in on the document irrelevant which language the document is in. Yes, as you said, I can overwrite it on a document level, but that's a nightmare to manage.

@peter2, Okay, gotcha! I see that Phil has added that to our feature tracker. Thanks for the info :slight_smile:

  • I'll share your feedback about seeing what content exists in different languages with our UX team. That's really valuable to know.
  • Your point about getting meta for alt langs is really interesting. We've discussed this issue before, but I've sent your feedback to the product team.
  • Phil addressed the question about alt text.
  • I've submitted a feature request for a multilingual document ID.

Thanks for all of this feedback, @peter2! This is exactly what we need as we grow and continue to offer the best product possible :pray:


This is being tracked as an open feature request.

If you have another use-case for this feature, you can 'Flag' this topic to reopen. Please use the :heart: button to show your support for the feature and check out our Feature Request Guidelines.