A little update:

I just took two different localized builds and compared their hashTables from ngsw.json. Their assets' hashes are totally identical when using application builder, so i can assume, this feature can be done without pain.

Hi guys. I see “Needs discussion” badge was added, what does it mean? Will this be done?

needs: discussion means that this issue needs to be discussed further with the rest of the team.

We already discussed this during one of our team meetings but we haven't reached a definitive conclusion on the next steps. However, we reached a consensus that if an action is taken, it's improbable that it will involve a symlink-based approach.

Spent some time discussing this in the team today. Our immediate reaction is that symlinks in the output might cause some issues for servers. In my experience, servers are typically hesitant to follow symlinks as they can often be the result of a misconfiguration issue and accidentally serve data which wasn't intended to be served. In this case, such symlinks would be internal to the served directory and (probably) safe, but I could see some servers getting this wrong or requiring explicitly enabling symlinks which server admins might not want to do.

An alternative proposal which might be better is to just emit an assets/ directory independently of the locale. That way there is only one copy of the assets. This has the additional benefit that there is only one URL for each asset. This way if a user downloads /assets/foo.png and then switches locale and re-requests /assets/foo.png, the URL is consistent and the browser cache can respond more quickly. This would also mean absolute paths can be used for requesting assets without having to manually include the locale.

This would definitely be a breaking change for existing applications, so I don't think we can automatically make this change, it would need to be behind a flag. Not sure what the naming for this flag would be, but under i18n options we could include something like singleAssetDir: true to enable this behavior. I do like this approach in general, and if it works out in practice we might want to consider enabling it by default for new applications, even if we don't necessarily have a path to automatically migrating existing apps.

This sounds like a good solution. I dont think there are many people who use i18n + ssr now, so it won’t break many apps. Maybe make this approach as default and add option like { cloneAssetsForEachLocale: boolean } (which is false by default)?

This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list.

You can find more details about the feature request process in our documentation.

This feature would not only reduce build sizes considerably and improve caching, it also enables to output static files outside of the locale directories (favicon.ico, robots.txt, .well-known, etc.).

I wish I could upvote this a million times.
We have an application with a gazillion locales. For deployment we copy a local assets folder into the root folder of the dist folder, then recursively delete all the "locale" assets folders. But it's quite messy . Having a "non locale sensitive" assets would be really useful

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

@dgp1130, have you also considered not copying the global style files to each locale? Those defined in projects > myapp > architect > build > options > styles.

Is there any use case where they can be different depending on the locale? Thanks.

Hi, is there any chance to reconsider this vote, please? This is vital for new applications and especially containerised ones. I totally agree with @spock123 to upvote it more than one million time. By the way, what is the minimum requirement vote to push it back to the backlog?

I definitely think that this is something that should be considered again.

This is still bad DX managing files like robots.txt. It would be nice to have a way to create a single folder for assets out of locales folders