Demo for making backend code know browser's locale and timezone

[wxiaoguang]

A demo for

• Replace inline script for critical JS with standalone script #21429 (comment)

Then backend code can render contents with correct locale and timezone, there will be no UI flicker on frontend.

Try it in a private window.

---

Some backgrounds and discussions: #21429

In short, at the moment, backend code doesn't know user's timezone, so rendered date/time would be in wrong timezone.

There could be 2 approaches:

1. Re-render the date/time by JS again, which may cause some flickers on UI, to avoid flicker the code would be somewhat hacky and IMO not stable (PR Replace inline script for critical JS with standalone script #21429).
2. Make backend know the browser's timezone (This PR, for demo), which will make a second request for user's first visit. Or we can choose to only render correct timezone for later visits.

Which way should we go?

[silverwind]

Hmm, this could work, but would only be active on second page load, but that's not a big issue. If we wanna go the backend route (and I would certainly prefer), we should probably reject #21440 now.

[silverwind]

The real question is thought: How does go's date formatting hold up to JS Intl? Is it "good enough"?

[wxiaoguang]

The real question is thought: How does go's date formatting hold up to JS Intl? Is it "good enough"?

It is something still needs to be investigated, and I think we can wait for more time to collect more voices from other maintainers about the locale/date format problem.

[silverwind]

Yes, we need a decision between this PR and #21429 (comment).

This PR:

• does not work on first page load or for users who block cookies
• would need to rely on golang intl which may be "weaker" than JS intl

My PR:

• has non-straightforward initialization via requestAnimationFrame
• requires one additional fetch to the server for a tiny script

[silverwind]

I would not do this reload, just live with the fact that it works only on second page load. There is certainly the danger of a reload loop when something goes wrong otherwise.

[wxiaoguang]

Yup, I could also agree so.

[wxiaoguang]

ps: cookie won't be a problem, the CSRF token and Gitea session cookie are all there, unless only the document.cookie doesn't work ....

[silverwind]

We don't need to communicate window.navigator.language, as we already have the language from the chosen language setting (reflected in document.documentElement.lang).

[wxiaoguang]

That's another question needs to be discussed. window.navigator.language is user browser's default language, which is different from the user chosen language for Gitea document.documentElement.lang.

So I just report the navigator language as it is, then backend can know: browser's default language, user chosen language.

---

Indeed the navigator.language could be removed if it's useless in the future.

[silverwind]

I think the only place we should rely on window.navigator.language is to determine initial language for users that have set none, e.g. a auto language could be added that defaults to window.navigator.language, similar to the auto theme.

[silverwind]

My opinion: I still prefer #21429 because JS Intl APIs are more powerful and because it works on first page load too. And secondly, because I'm more fluent in JS than golang.

[wxiaoguang]

I could also agree with #21429 if there would be a stable solution for the case:

<script init.js />

<time id=time1 />

<!-- 
very long content, which need a few seconds to transfer, 
then browser will partially render the content above,
while the remaining content will be rendered a few seconds later.
 -->

<time id=time2 />

<script index.js />

[silverwind]

I'm sure there is a solution, but it can't be doing requestAnimationFrame indefinitely, some way to exit the recursion must be there (at worst, it could run into the call stack limit of JS).