You could use Lexical.Localization¹ as localization solution for modular parts, such as class libraries. The localization will work independently for each library. Libraries can both A) embed their own localizations within, and B) have localizations be published along as files.
If you write your class libraries initially for just one or two languages, you can inline the strings right into the code, even use $string_interpolation.
And when the deployer of your class library wants to expand with their own localization (Application supplying localizations). They can add localization as files.. or provide one within the Program.cs code as simple lines, such as Dictionary.
public class MyClass
{
/// <summary>
/// Localization root for this class.
/// </summary>
static ILine localization = LineRoot.Global.Type<MyClass>();
/// <summary>
/// Localization key "Ok" with a default string
/// </summary>
static ILine ok = localization.Key("Success").Text("Success");
/// <summary>
/// Localization key "Error" with a default string.
/// </summary>
static ILine error = localization.Key("Error").Format("Error (Code=0x{0:X8})");
public void DoOk()
{
Console.WriteLine( ok );
}
public void DoError()
{
Console.WriteLine( error.Value(0x100) );
}
}
Localization file can be written as .xml, .json, .ini, .resx, or with your own format.
[Type:MyClass:Culture:fi]
Key:Ok = Onnistui
Key:Error = Virhe (0x{0:X8})
¹ (I'm maintainer of that library)