Feature request: structured UI localization / i18n support

[Micuks]

Is your feature request related to a problem? Please describe.

MicroBin currently has its UI strings embedded directly in Askama templates and endpoint-rendered pages, which makes it difficult to:

• run the same instance for users in different languages
• add translations without touching many templates
• keep upstream and downstream forks aligned when translating UI text

There is already an older question about this in #133, but I think the project could benefit from a more concrete feature request for proper UI localization support.

Describe the solution you'd like

Add a small, structured i18n layer for the web UI with English as the default/fallback locale.

A minimal but useful scope would be:

• centralize user-facing UI strings instead of hardcoding them across templates
• select locale from Accept-Language with fallback to English
• optionally allow an explicit override such as ?lang=xx
• start with en and make it easy to add more locales incrementally
• apply it to the main user-facing pages first:
  • header/footer/navigation
  • create/upload page
  • upload detail page
  • edit/auth/list/guide/error pages

I am not necessarily suggesting a large dependency or a complex translation framework. Even a lightweight internal abstraction would already make this much easier to maintain.

Describe alternatives you've considered

• Maintaining translations in downstream forks only.
  • This works for one deployment, but every UI change becomes harder to rebase and maintain.
• Hardcoding a second language directly in templates.
  • This solves a local need, but does not scale and makes review/maintenance harder upstream.
• Keeping English-only UI permanently.
  • This is the simplest option, but it limits usability for non-English users on public/shared instances.

Additional context

I recently implemented a local proof of concept for a self-hosted deployment on microbin 2.1.4 that:

• keeps English as default
• serves Chinese UI text when the request prefers zh
• leaves English responses unchanged for non-Chinese requests

That experiment worked well enough to confirm the feature is practical, but the local patch is not polished enough to submit as-is because it still spreads string handling across templates.

If this direction is welcome, I can help turn it into a cleaner PR with:

• a centralized string layer
• request-based locale selection
• one additional locale (zh-CN) as a reference implementation