Replace the PostBuild process with an embedded resource solution about i18n HOT 9 CLOSED

I've taken a stab at this by embedding them.. sorry I haven't had a change to submit back. Will find time in the next month to clean up and submit a pull request:

https://github.com/colinbowern/i18n/tree/master/src/i18n.PostBuild

from i18n.

Thanks. I'll see what I can use from that---though I suspect I'll want to
do the embedding in i18n.dll have the extraction happen on demand at
runtime, as an option, like how ZeroMQ handles it.

On Tue, Jan 29, 2013 at 12:10 PM, Colin Bowern [email protected]:

I've taken a stab at this by embedding them.. sorry I haven't had a change
to submit back. Will find time in the next month to clean up and submit a
pull request:

https://github.com/colinbowern/i18n/tree/master/src/i18n.PostBuild

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-12845584.

Daniel Crenna
Conatus Creative Inc.
cell:613.400.4286

from i18n.

@colinbowern I took a quick look and you have some other really nice enhancements here, so I think I'll want to bring them in. I'll let you know if I end up bringing them in before you do.

from i18n.

Also, why does PostBuildTask need to be inside i18n? Shouldn't it be in the i18n. PostBuild project? That class doesn't have any behavior in there that is not using msmerge and xgettext (I mean, besides going through the cs and cshtml files), hence I don't see it as an extension point or something that can be reused in another context besides an executable.
It even feels to me all the external tools could be packaged with the PostBuild executable.

from i18n.

True, and fair point. I was just thinking about the possibility of a
runtime scanner where you could rebuild your PO templates on
Application_Start, for example, inside the I18N.Register() method, so it'd
be one less thing to manage.

On Tue, Jan 29, 2013 at 1:49 PM, Raul Vejar [email protected]:

Also, why does PostBuildTask need to be inside i18n? Shouldn't it be in
the i18n. PostBuild project? That class doesn't have any behavior in there
that is not using msmerge and xgettext (I mean, besides going through the
cs and cshtml files), hence I don't see it as an extension point or
something that can be reused in another context besides an executable.
It even feels to me all the external tools could be packaged with the
PostBuild executable.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-12850735
.

from i18n.

I agree that anything that can be done to simplify managing the synchronization between the template and the application is a positive thing. But given that you don't want that slowing application restart and that with any change you would have to wait until the new strings have been translated in the PO files anyways, it really feels as an action that should be done offline as part of the application management process and not necesarily as part of the application building or running.
I actually think a post build action is a good option although I would actually prefer an external tool that can be run for the project 'on-demand'.
After you've merged the gettext libraries into postbuild i was actually thinking of wrapping it as a visual studio extension that will add a menu command that could be executed on top of a 'valid' project.

from i18n.

+1 @raulvejarI Sometimes the Hosting is restrictive of starting a new process from inside a website(for example Azure Websites) and building the .PO files in App_Start could pose a problem. This is more administrative task and should be handled that way.

from i18n.

Okay, we'll do it that way. I've always had a bias for dynamic processes
for migration, minification, etc., but understand some don't work in full
trust or want to sacrifice their CPU in production environments.

So we'll do it your way and perhaps I'll just reference a hook for my own
purposes.

On Wed, Jan 30, 2013 at 4:04 AM, Apostol Apostolov <[email protected]

wrote:

+1 @raulvejarI Sometimes the Hosting is restrictive of starting a new
process from inside a website(for example Azure Websites) and building the
.PO files in App_Start could pose a problem. This is more administrative
task and should be handled that way.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-12880237.

from i18n.

I believe issue #58 addition to v2 branch addresses this.

from i18n.