Ver Slow Drupal on Translated Nodes/Many Internal Redirects To Translated Pages/ Late Server Response Time 15s Due to Drupal Translation Logic

I haven't been able to reproduce this given the steps above.

I did the following:

1. Installed Drupal 10 with https://simplytest.me.
2. Installed the Content Translation module and added a second language.
3. Configured the article content type to be translatable.
4. I created an article node in English.
5. I added a node translation in the second language.
6. I browsed to the published second language node.
7. I did not observe a performance problem.

So, you will have to continue to investigate on your own and you must provide much more detailed steps to reproduce that can be followed by contributors.

I did the same following your steps and the the translated document requested from the server taking time more than the default language node time.
attached is how long took to response from server and the node is only text document.

It could be a platform problem on your end. Have you profiled the PHP execution?

maybe yes but I checked different server installations and the same performance issue is replicated and caused mainly by the settings of */admin/config/regional/language/detection (Detection and selection).
fresh installation comes with only one setting enabled Language from the URL (Path prefix or domain). with Customize Content language detection to differ from Interface text language detection settings disabled.
so later if the second option is altered there will be maybe 2 separate translation files/requests which causing server to make 3 types of redirect(301/307/202) before sending the response to the browser and this option is not possible to revert back to first default detection settings otherwise only Interface gets translated and the body and title will remain the default language and even access to to content will not be possible and performance issue will disappear as the body and title translation fields will not show.
the only solution now is to keep detection settings as default and to touch them.

This needs step by step instructions to reproduce from a clean Drupal installation. Your initial post doesn't mention having the interface and content translations as different.

I just wanted to prove that the language detection system has bugs even on default installation which will make later performance issue on some translated pages (nodes).
to reproduce what is in the last post video.
1- fresh installation.
2-add english as a second language for example.
3-add 1 translated article.
4- /admin/config/regional/language/detection and enable (Customize Content language detection to differ from Interface text language detection settings) uncheck all possible options then save.
5- now not possible to edit translation.
6- disable (Customize Content language detection to differ from Interface text language detection settings) with all its option unchecked.
7- and still system will not be able to show or edit translated content and error logged ( /en-gb/admin/content/files. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException...)
* many scenarios are there for the same error but this is straight to the point.
*attached is happening only on some translated article node with small size.

Hello,

I’m interested in contributing to Drupal but am unsure where to start. Could someone guide me on the best way to get involved or recommend any beginner-friendly issues and resources?

Thank you!

Best,
Nikunj

@iselectweb We need that information in the issue summary or unfortunately this issue will not get attention.

@nikunj_24 See https://www.drupal.org/community/contributor-guide →

@iselectweb Are you able to reproduce the bug on https://simplytest.me?

@cilefen
the latency issue not yet able to reproduce it on simplytest.me but the language detection error was on clean installation on the same site.
the issue is not all translated nodes have the performance issue even on the same site which makes reproduce more difficult but I am still trying to get there.

Have you profiled → to find out what exactly is slow?

https://lawyers-dubai.com/
this website is english and Arabic if could please have a look to the home page and click on Arabic from language selector block on the top,
the website has lite-speed server images served from cloudfront it has only 4 webp images and it take time to open translated home page even every time you visit the page and redirect sometimes shows on the network.

-other websites editing and saving translated pages takes 1 min and more posting comments on them takes more and more time.
server support they confirmed all works well from their end.
I am trying to find what makes this behavior.

@iselectweb do you definitely need the content and interface languages to be different?

You generally only need this if you have e.g. admins working on the site in English who want to keep an English interface even when viewing Arabic content when otherwise everything is translated.

And does the issue only happen when this setting is enabled?

@catch I have the performance issue on all ui settings for language detection and what found is even if (Customize Content language detection to differ from Interface text language detection settings) is disabled, system still detects all checked options inside it and behave accordingly.

-/admin/config/media/file-system(Interface translations directory) this setting is useless for the languages folder and its js file and will respect only translations folder regardless where the language folder is located.

-The s3fs S3 File System is enabled for public files: now all assets will remain on local file system like css/js etc even assets injector module will use its files locally like others except /sites/default/files/languages/file.js this file will be served from s3 bucket and will be requested from other js local file during execution time and maybe this is causing redirect and blocking in the main thread and making performance issue.

-with use of s3fs public files if languages folder is removed from local sites/default/files/languages/ no error will be thrown and system will not create new folder etc.
if the same folder ( sites/default/files/languages) is removed from s3 bucket, system will create new empty folder and will throw error from the page requesting this language and translation will show even with errors. (errors attached error1/2).

maybe this logic is causing issues with translated pages and I don't know why languages/file.js needs be requested and served from s3 bucket like a very external file or an image to be lazy loaded.
ps. I used s3fs for private files only and translation performance was much better than s3fs public files.

@iselectweb please try to post steps to reproduce this issue from a clean Drupal install, it has taken 18 comments to find out that you're using s3fs module.

JavaScript translations are created on demand, so if s3fs is storing them, that may not be helping.

One issue related to this is 📌 Remove on-demand JavaScript translation parsing and do everything on rebuild Needs work .

It might be worth a new issue to discuss moving generated JavaScript translation files to the assets:// stream wrapper so they can be kept out of s3 - see https://www.drupal.org/node/3328126 → for details.

Dear maintainer @catch now it is not possible to reproduce on only clean installation without s3fs installed to handle public files.
and agree it is not s3fs fault if it copies all public folder and then core modules and handler will ignore locally stored assets and search for this file externally without explicit configuration.
To reproduce attached errors last post:
1-Clean installation.
2- s3fs to handle public files
3- Delete language folder from s3 and keep the folder stored locally.
4- Two errors from translated page that belongs to the language deleted from s3.

I am making this a support request as there is no clear indication this is a Drupal Core bug. It's some setup issue with S3 and possibly an unanticipated use-case.

Dear @cilefen can you please wait till we have the last comment from @catch?
This is core assets, s3fs has nothing to do with it and the file is requested during execution time and not initiated earlier like images and other files from s3.

Thank you🤍

We need the information from comment #19 to proceed. The steps you gave continue to cite S3. Provide the steps to reproduce the bug on a newly-installed Drupal site that you verify are reproducible.

Translated JavaScript files are always stored in the public files directory:

 $dir = 'public://' . \Drupal::config('locale.settings')->get('javascript.directory');

As I said already in #19:

It might be worth a new issue to discuss moving generated JavaScript translation files to the assets:// stream wrapper so they can be kept out of s3

But that should be a new, clearly defined, task against Drupal core - and it's not yet been demonstrated that this is the cause of the performance problem described here.

@catch ok noted, @cilefen lets close this issue since demonstrating what is technically happing is beyond my skills and ability.
thank you all.

@iselectweb I've opened 📌 Use the assets stream wrapper for translated javascript files Active . The actual code change should be pretty minimal, so once there's an MR, one way to demonstrate the problem here would be to try it out and see if it helps or not. I think that issue makes sense in its own right even if we don't have conclusive information about the problem you're experiencing - the generated javascript translation files are pretty similar to asset aggregates. Can't guarantee if/when I'd be able to work on that issue but please follow - it's also possible someone else will pick it up.

@catch well that sounds great I am following the issue you have created.
even if it might not solve the issue but at lease it will be aggregated with other core/theme .js files and this will reduce queuing time.
Thank you.