[eeps] EEP XXX: Documentation storage and format
Loïc Hoguin
essen@REDACTED
Sat Jan 6 12:48:00 CET 2018
On 01/06/2018 12:19 PM, José Valim wrote:> For translations, we could
accommodate a similar change. We could
> introduce a map
> where the key is the language and the value is the documentation:
>
> Doc :: none | hidden | binary() | %{binary() => binary()}
>
>
> The above attempts to be backwards compatible but it is worth noting the
> whole
> documentation tuple is versioned. If push comes to shove, we should
> be able to bump
> the tuple version.
>
> I am completely OK with changing the proposal to use a map to store the
> documentation
> in order to support translations. Although I would like to hear others
> on the balance
> between supporting it upfront vs. adding it later on when necessary.
Considering the number of projects that currently come with translations
(close to zero) I think it shouldn't be a problem to postpone it.
It's also not as simple as it may sound. It would probably involve
language tags which are already well defined and also have a language
selection algorithm that's well defined (if user wants "en-GB" but only
"en" and "fr" are available it will select "en"). What's not defined
however is how the Erlang tools know which language the user prefers in
a portable way (on Linux we have the LANG environment variable, but on
Windows?).
So this needs a bit of research and experiment before something viable
can be done in a consistent manner.
That said perhaps the first version of the EEP can change binary() to
#{binary() => binary()} as this part is unlikely to change, and require
that the map contains at least one element where the key is <<"en">>.
That way tools can experiment with translations in a backward compatible
manner.
Cheers,
--
Loïc Hoguin
https://ninenines.eu
More information about the eeps
mailing list