You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present, the i18n library is coupled to IIS / System.Web. This means that it doesn't support OWIN web apps unless they too are built on top of IIS / System.Web (Microsoft.Owin.Host.SystemWeb) (see #241 and https://github.com/turquoiseowl/i18n#owin-support).
With the view to enabling a pure OWIN middleware version of i18n, it may help to gauge the work required to decouple i18n from System.Web/IIS. So here is a listing of classes and static methods (outside of the HttpModule pipeline classes) that would require abstracting in some way:
i18n
Interfaces for abstractions of the above.
Common concrete classes i.e. any class that doesn't currently reference the
above or can be converted to reference the new abstraction interfaces.
i18n.SystemWeb
Implementations of above abstractions for IIS/System.Web webapp.
i18n.Owin
Implementations of above abstractions for OWIN webapp.
Your thoughts are welcome. This may all be hyperthetical as I'm mega tied up with other work at the moment and don't need this myself just now. If someone does need it and wants to have a go I'll provide what help I can. Thanks.
The text was updated successfully, but these errors were encountered:
I recently created a console application to translate string in JSON files, offline, no web server invovled. I used TextLocalizer and repositories and it worked really well. This made me thinking maybe we should make this the i18n core more generic that you can use it in Console, Winform, Web and even Mono on Linux. In general the .NET internationalization is really cumbersome and broken so this would be super cool.
The i18n.SystemWeb can tap into HttpContextBase and localize http response.
The Owin can tap as a middleware and localize http response.
Others can even contribute and make Winform adapters to translate PO into resx resource file.
This way it's also a lot easier to make custom console utility to convert PO to any file format.
At present, the i18n library is coupled to IIS / System.Web. This means that it doesn't support OWIN web apps unless they too are built on top of IIS / System.Web (Microsoft.Owin.Host.SystemWeb) (see #241 and https://github.com/turquoiseowl/i18n#owin-support).
With the view to enabling a pure OWIN middleware version of i18n, it may help to gauge the work required to decouple i18n from System.Web/IIS. So here is a listing of classes and static methods (outside of the HttpModule pipeline classes) that would require abstracting in some way:
A revised namespace hierachy could be as follows:
Your thoughts are welcome. This may all be hyperthetical as I'm mega tied up with other work at the moment and don't need this myself just now. If someone does need it and wants to have a go I'll provide what help I can. Thanks.
The text was updated successfully, but these errors were encountered: