POTools localizable string extractor about aspnetskeleton2 HOT 3 OPEN

Hi there!

I'm glad that my localization solution has caught your attention (even despite the lack of docs). The implementation in this repo is like the third iteration of the concept, so I might say it's pretty polished.

My answers:

1. I've already thought about extracting the POTools project but I came to the conclusion that in its current state it's not generic enough to be worth distributing separately from this project. It'd need some more work to make it properly customizable so that it can cover a wider range of use cases. (E.g. it should be able to pick up translation texts from SPA or Blazor clients or, at least, provide some extensibility for consumers so that they can achieve things like that.) This may happen eventually but I can't yet see when, so I'd rather not make promises.

   As for now I suggest you copy POTools to your project and use it as a local tool as shown in this solution. The core idea is that tool projects are configured to emit NuGet packages to a solution directory when running dotnet pack and the output is used as a source to dotnet tool restore. Just examine the restore-tools.cmd script and you'll get a grasp of the idea. This setup even has some benefits over a published NuGet package: you can have different versions of these local tools adjusted to the actual project and you can make changes to them without much hassle at any time. You just issue restore-tools.cmd -f and you're ready to use the updated tools.

2. This decision has two main reasons:

   • Matching strings based on member names requires syntactic analysis only. To identify types, you have to do semantic analysis, which is a further step. Roslyn, the compiler API used by the tool, is capable of that, so it's absolutely doable. I just found it didn't provide much benefit, so didn't bother. I'm aware of only one bigger shortcoming of syntactic analysis: you must use exactly the expected names, qualified names won't work. I decided I could live with that compromise.
   • Another aspect is that I may have assemblies (e.g. API contract assemblies) which I don't want to make dependent on Microsoft.Extensions.Localization.Abstractions (the assembly containing IStringLocalizer) yet want to enable translation text extraction in those assemblies too. The current solution enables me to define a fake localizer interface for the purpose of extraction in such situations.

3. You can pass an MSBuild project file (e.g. csproj) to the scan command using the -p option (see dotnet po scan -? ) and it will then only list source files included in the project.

I hope this will help you. Just let me know if you have further questions.

from aspnetskeleton2.

Thank you for your prompt answers, they're very helpful!

Re 1) and 2):
I'm not sure I would want to go down the whole SPA rathole - that feels like a whole different can of worms. I do like the idea of the tool being extendable, thought - maybe by allowing for arbitrary ILocalizableTextExtractor implementations to be registered/injected and allowing anyone to write an extractor for their specific needs.

I'll think about this some more and try to come up with a proof of concept when I have some free time. Maybe we can go from there.

Re 3):
I've tried doing that, but in my case, the tool simply gets stuck. I can, however, provide it a directory and it works fine. So basically: dotnet run scan --project-path ../SomeApp/ works, but dotnet run scan --project-path ../SomeApp/SomeApp.csproj does not. I am on macOS, running thi .NET Core 3.1.102.

I'll look into why this is, but it's probably something trivial.

from aspnetskeleton2.

I'll think about this some more and try to come up with a proof of concept when I have some free time. Maybe we can go from there.

Ok, the idea may be worth some exploration. However, I'm still not convinced that even an extensible tool published on NuGet would be a significant improvement over the solution we currently have. The possibility of quick and easy modification for tailoring the tool to the particular project's needs is a nice feature. By enabling extensions we'd achieve something similar but in that case the process of the customization seems to me somewhat more rigid and awkward. Anyway, feel free to play with this but please be aware that I can't really afford to maintain another project anytime soon.

I've tried doing that, but in my case, the tool simply gets stuck. I can, however, provide it a directory and it works fine. So basically: dotnet run scan --project-path ../SomeApp/ works, but dotnet run scan --project-path ../SomeApp/SomeApp.csproj does not. I am on macOS, running thi .NET Core 3.1.102.

I'm on Windows and have never encountered such an issue there, so I suspect it has something to do with macOS. The tool uses Buildalyzer to analyze MSBuild project files. Unfortunately, I don't have a Mac, so I can't do tests but first I'd try to upgrade Buildalyzer to the latest version and, if that doesn't solve it, would do some debugging around here.

from aspnetskeleton2.