use values instead of keys to inferr method signatures

[earloc]

Synopsis

People seem to want to utilize other storage-formats to leverage statically typed method-signatures when used with storage-formats other than *.resx-files.
Even as code-first (#78) takes a whole opposite approach when it comes to think about the source-of-truth for getting statically typed signatures of translatables and even progressed to make some big steps into reality, recently (see #86 and #88), there is still some work to be done to support alternating formats (like #95) other than *.resx.

So I again started to think of what is currently preventing us from getting other storage-formats to act as the source-of-truth for gaining type-safety, leveraging resource-first as the source-of-truth.

What is preventing us from making this a reality?

The nature of resource-keys vs. the nature of resource-values!

Explain that!

In it´s initial incarnation of TypealizR, I went the route to using a resource´s key to act as the source-of-truth for generating method-signatures. This is due to the fact that this approach opened up the possibilty to create a completely customized way of defining types and names used as inputs for the source-generator (See currently supported parameter-types )

However, different storage-formats seem to have different constraints over the nature of keys within a resource, like :

• *.po-files requiring an NMTOKEN,
  See Give us the power of code-first-i18n #78 (reply in thread)
• *.resj-files requiring the key to be a valid C#-identifier

And what now?

I´m starting to think about a possibility to leverage a storage-format's value to infer method names and parameters from - in contrast to currenlty using a resource' s key .
This would open up the possibility to support these storage-formats as valid inputs to the source-generator.

But this imposes another "problem": no freedom over the actual parameter-specifications!

*.resx or *.resj-fiels

Both *.resx or *.resj, rely on string.Format as an ultimately implementation detail to actually format a string. That means that

• parameter names are constraint to be indexed-based( {0}, {1}, etc.)

  which would produce method-signatures like `` hello(string _0) -> "hello world"
  at least without the need to perform some kind of replacement code injected into the generated code, which definetly may hurt performance (more or less)

• types can only be possibly inferred by inspecting the format-specifier provided on such index-based paremeters

  which at least sounds like a challenge, but looks solvable

*.po-files

From what I understand, *.po-files do not provide something as a paramter-name or -index, but purely rely on positional-parameters, like the following sample suggests (borrowed from here):

msgid "Welcome %s"
msgstr "Willkommen %s"

Supporting this in a meaningfull way seems even more challenging right now, as there

• is no meaningful name inferrable other than an index
• the format-specifier might be hard to deduce a valid .net-typefrom

These concerns may originate from my limited understanding what *.po-files really look like and offer to us, despite their outstanding support for plurals, obviously.

Nevertheless, I think all these above concerns a adressable in a way we all could benefit from.
So I request the world for comment, to make futures .net-dev-lifes a bit easier (including our own, possibly ;) ).

@MarkPflug, @ivanhofer, @dodyg, @kant2002
Any suggestions?