search

DarkoKukovec / I18n-harmony

I18n library with ES2015 syntax
5 stars 0 forks source link

date, numerical locale support #18

Open bsbechtel opened 7 years ago

bsbechtel commented 7 years ago

Is there a way to handle date and numerical support for different locales? I.e., dates being mm/dd/yyyy in some places and dd/mm/yyyy in others. Would you need to use the findTranslation or postProcessor methods to write your own handler?

DarkoKukovec commented 7 years ago

Hi @bsbechtel, Handling date and number formats are an I10n functionality, not I18n. Therefore this lib is not handling it.

You can use the findTranslation method to override the default logic of finding the translation keys, but unless you have the date formats as the key (which you shouldn't), it won't be useful to you. You could use the postProcessor method to find the date format inside of the translation string and transform it into a real date, but I'm not sure this is the best approach. You could have a date format (or money format) as a separate translation string and then pass it to a formatting library (e.g. moment.js)

Does this fit into your use case? If not, can you please describe the use-case?

bsbechtel commented 7 years ago

Hey @DarkoKukovec, thanks for responding to this right away! I ended up writing a postProcessor method that uses moment to reformat the dates. I used the translation string to define the desired format for the given locale, and passed the actual date as a keyed value in the options object to the translate method.

I think this is more or less what you suggested using postProcessor above. I haven't done numbers/decimals yet, but most likely will have to.

I believe I figured out my own problem, but do you have any interest in expanding the library to handle i10n functionality? I'm actually using the react-mobx-translatable library on top of this one to inject the values into my React components. It's not much, but I could contribute the methods I write to it.

DarkoKukovec commented 7 years ago

Hi @bsbechtel. I would like to implement L10n support, but that would most likely be as a separate library. Since L10n is a much harder to implement compared to I18n, I'm sort of hesitant to start.

bsbechtel commented 7 years ago

I completely understand. When I finish up this project, how about I can at least share my postProcessor methods for my work. That might at least give you some ideas on how you can expand or create a new library to handle the use cases I still needed to cover. Sound good?