I'm working on the hypha creation form patch [1] and wondering how I 
should approach translation since my previous patches have had issues 
around this...

For views, the boilerplate.md file recommends using a template string
stored in the $view_pkg/$view_pkg.go file (hypview/hypview.go in this 
case) alongside the $view_pkg/view_$name.html file. 

But the l18n package claims to handle 
> everything language-related for Mycorrhiza.
and I do see it used as viewutil.Meta.Localizer in some places, 
especially for error messages.

However I see it used most by *.qtpl files and in combination with 
viewutil.Base() and viewutil.HttpErr(). Since all of those are being 
phased-out, am I correct in assuming that l18n is too?

So I assume I should put translations for the current views in the 
appropriate ruTranslation string in hypview/hypview.go, but what about 
the translations for the errors returned from handlers in web/mutators.go?

Should I:

1. put them in the l18n/*/ui.json files to be fetched with lc.Get() and 
fed into a viewutil.Base() call? This seems to be current/past practice.

or

2. put them in the hypview/hypview.go and access them from web/mutators.go 
for use in a viewutil.Base() call? This would keep the related 
translations togethor and since hypview is already imported by web, it
already can access the translations there.

or

3. create a new package for error views? This could later be used to 
replace all uses of viewutil.HttpErr(), but of course would be more 
work up-front.

or do something else?

If you need more context, I'm pushing my work-in-progress here:
https://git.sr.ht/~roselandgoose/mycorrhiza/log/creation_flow

-Rosie Keith Languet

1: https://lists.sr.ht/~bouncepaw/mycorrhiza-devel/patches/37333

Yes, the l18n package is being phased out. It is still around, and is
being used in some places, but it should not, when possible.

> So I assume I should put translations for the current views in the 
> appropriate ruTranslation string in hypview/hypview.go, [...]

Correct.

> but what about the translations for the errors returned from
> handlers in web/mutators.go?

You should:

> 1. put them in the l18n/*/ui.json files to be fetched with lc.Get()
> and fed into a viewutil.Base() call? This seems to be current/past
> practice.

While this approach is not really good, this is how it is done in
most other places. In the future I want to carry out a major error
page update, during which it would be easier if older error pages are
uniform. So, stick to the best practice, thank you.