Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some suggestions to humanizer #105

Closed
mdmoura opened this issue Mar 18, 2014 · 2 comments
Closed

Some suggestions to humanizer #105

mdmoura opened this issue Mar 18, 2014 · 2 comments

Comments

@mdmoura
Copy link

mdmoura commented Mar 18, 2014

Hello,

I tested Humanizer on an ASP.NET MVC CMS project and I have a few suggestions:

1 - Add a HumanizerConfiguration for startup
This would be used to define, for example, custom translations.
The translations could be use a Fluent API.
This would be more flexible then having Resource files built in Humanizer.

2 - Add the option for enum humanizer to allow a different attribute than Description.
Again, this could be applied in HumanizerConfiguration.

3 - Add extensions points to humanizer ...
I could create an extension to do some type of conversion ...
This way people could start to create humanizer "plugins" and share.

What do you think? Just some ideas from my short experience with Humanizer.

Thank You,
Miguel

@MehdiK
Copy link
Member

MehdiK commented Mar 19, 2014

Hi @mdmoura,

Thanks for the suggestions. I will try to add my comments for each:

  1. custom translations: translations in Humanizer could be very complex for some languages (check out the Arabic translation code and the associated resource file with many additional resource entries compared to English). There are hooks in the framework that allow translators to implement their complex translation logic more easily. All in all, providing custom translation has been one of the harder areas of Humanizer. The other thing is that if there doesn't exist a translation for your language, you could help the community by adding it in the framework so others could benefit from it too. If it's just a customization to how a particular existing translation has been done, you should be able to do that by overwriting the corresponding resource file.
  2. When you say a different attribute than Description you mean a subclass of it or just a completely custom attribute?
  3. As it stands Humanizer is all made of extension methods and you can obviously create you own extension method to complement it. What am I missing?

@MehdiK
Copy link
Member

MehdiK commented Apr 3, 2014

The second suggestion has now been implemented in the framework as part of #108. Basically ANY attribute applied on enum members with a string Description property counts. This is to help with platforms with missing DescriptionAttribute and also for allowing subclasses of the DescriptionAttribute.

I am closing this now as I am a bit unsure about the 1st and 3rd suggestions and haven't heard back from you. Happy to reopen this to discuss further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants