[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