The erli18n library's application callback: the OTP entry point that brings the process tree up and down.

What it is and what problem it solves

This is the module pointed to by {mod, {erli18n_app, []}} in erli18n.app.src. When someone runs application:ensure_all_started(erli18n) (or the release boot), OTP calls start/2 here, and when the application stops, it calls stop/1. There is nothing erli18n-specific in it beyond delegating: it exists because the application_controller requires a callback module, not because there is any i18n logic to run at boot.

Mental model (for the maintainer)

Think of this module as the thinnest possible shell around the supervision tree, with ONE cleanup responsibility on shutdown. The load-bearing complexity lives one hop ahead:

• start/2 calls erli18n_sup:start_link/0 and returns the supervisor's {ok, Pid} raw, unwrapped. That Pid becomes the pid of the application that the application_controller goes on to monitor.
• The real topology lives in erli18n_sup: a one_for_one strategy with a single child — erli18n_server (worker/writer). The catalogs live in persistent_term (see erli18n_pt_store), which is owned by the runtime, not by any process, so a crash of the worker loses no catalog and the tree needs no table owner, no heir, and no child ordering. See erli18n_sup.
• stop/1 has real work: it erases the catalogs. persistent_term is node-global and is NOT cleared when the application stops, so without an explicit erase a stop/start cycle would leave stale catalogs behind (and a fresh start would see them as already loaded). stop/1 calls erli18n_pt_store:erase_all/0 to remove every {erli18n_catalog, _, _} term. This module reads no application:get_env/2: the env defaults (emit_lookup_telemetry, memory_warning_threshold, memory_warning_rate_limit_seconds) are declared in erli18n.app.src and consumed by erli18n_telemetry — never here.
• The ordered shutdown of the child (including the worker's terminate/2) is the supervision tree's job, triggered by the application_controller before it calls stop/1. By the time stop/1 runs the worker is already down, but the catalogs it installed still live in persistent_term — which is exactly why stop/1 must erase them here.

When a dev touches this module

Almost never directly. The normal path is:

• Library consumer: runs application:ensure_all_started(erli18n) and moves on to erli18n:gettext/3, erli18n_server:ensure_loaded/3, etc. Does not import this module.
• Maintainer: touches this only if the shape of the boot changes — for example, starting to read Args from {mod, {erli18n_app, Args}}, doing one-shot setup at start, or handling Type (normal vs takeover/failover in a distributed scenario). Today both arguments are ignored on purpose. If you are going to add a new top-level process, the place is erli18n_sup:init/1, not here — start/2 should stay a one-liner.

Quickstart

1> {ok, Started} = application:ensure_all_started(erli18n).
{ok,[erli18n]}
2> lists:member(erli18n, Started).
true
3> is_pid(whereis(erli18n_sup)).
true
4> is_pid(whereis(erli18n_server)).
true
5> application:stop(erli18n).
ok

The exact list in {ok, Started} depends on the environment. Since telemetry is declared in optional_applications in erli18n.app.src, if it is present but not yet started, ensure_all_started/1 brings it up too and includes it in the list (e.g. {ok,[telemetry,erli18n]}). The literal {ok,[erli18n]} above holds when telemetry is absent or already up; that is why the robust test is lists:member(erli18n, Started), not a comparison against the whole list.

See start/2 and stop/1 for the semantics of each callback.