cubos / sdkgen

[ DEPRECATED, SEE https://github.com/sdkgen/sdkgen ] Tool that aims on solving client-server communication and data layout sharing between server, web, android and ios using a description language also called sdkgen.
MIT License
45 stars 9 forks source link

Feature Request: notation human readable enums #10

Open tironiigor opened 6 years ago

tironiigor commented 6 years ago

It would be a feature so we could have an enum like

type Gender enum {
    female
    male
}

and then we could have

translator pt-br, default {
    Gender: {
        female: Feminino
        male: Masculino
    }
}

and it would generate a function to get the value for that translation given the phone Locale, and using the default value if the Locale trasnlation is not avaiable

dygufa commented 6 years ago

I would pretty much enjoy if we could define displayable values for enums, this would give consistence between plataforms on how we show these values.

However I would prefer a notation like:

type Gender enum {
    female: "Feminino"
    male: "Masculino"
}

In this scenario the i18n would be handled by an external file.

lbguilherme commented 6 years ago

Perhaps all languages could go into external files (i.e. have no default language)? And that external file be just a import with some sdkgen syntax for describing it (maybe similar to @tironiigor's?)

A proposal:

Create a construct to define translatable strings:

i18n en, en-US, default {
  female = "Female"
  placeNotFound = "The place was not found"
}

i18n pt-BR {
  female = "Femino"
  placeNotFound = "Local não encontrado"
}

Then this translation can be used in places where a string could be used, optionally. This is a mix of @tironiigor and @dygufa:

type Gender enum {
    female: i18n.female   // I can refer to i18n constants
    male: "Masculino"     // Or simply use a plain string
}

similarly those constants would be usable when implementing the api:

if (!place) {
    throw api.err.NotFound(ctx.i18n.placeNotFound);
}