L10NSharp 8.0.0-beta0021

.NET 8.0 This package targets .NET 8.0. The package is compatible with this framework or higher. .NET Framework 4.6.1 This package targets .NET Framework 4.6.1. The package is compatible with this framework or higher.
This is a prerelease version of L10NSharp.
There is a newer version of this package available.
See the version list below for details. 
dotnet add package L10NSharp --version 8.0.0-beta0021                

                    
                

            
NuGet\Install-Package L10NSharp -Version 8.0.0-beta0021
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package. 
<PackageReference Include="L10NSharp" Version="8.0.0-beta0021" />
For projects that support PackageReference, copy this XML node into the project file to reference the package. 
paket add L10NSharp --version 8.0.0-beta0021                

                    
                

            
#r "nuget: L10NSharp, 8.0.0-beta0021"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package. 
// Install L10NSharp as a Cake Addin
#addin nuget:?package=L10NSharp&version=8.0.0-beta0021&prerelease

// Install L10NSharp as a Cake Tool
#tool nuget:?package=L10NSharp&version=8.0.0-beta0021&prerelease

L10NSharp is a .NET localization library for Windows Forms applications. It collects strings which need localization when your application first runs and saves them in a XLIFF file. It can also dynamically collect strings at runtime.

Product Compatible and additional computed target framework versions.
.NET net8.0-windows7.0 is compatible.  net9.0-windows was computed. 
.NET Framework net461 is compatible.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 is compatible.  net481 was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (13)

Showing the top 5 NuGet packages that depend on L10NSharp:

Package Downloads
SIL.Windows.Forms.Keyboarding

The SIL.Windows.Forms.Keyboarding library provides cross-platform functionality for keyboard selection and switching in Windows Forms applications. Currently, this library supports system and Keyman keyboards on Windows, and X keyboard extension (XKB) and Intelligent Input Bus (IBus) keyboards on Linux.
SIL.Windows.Forms

SIL.Windows.Forms contains Windows Forms classes for UI elements (controls and dialogs) that are commonly used across various SIL applications. SIL.Windows.Forms is similar to SIL.Core in that it does not contain classes that are specific to any domain.
SIL.Chorus.LibChorus

End-user collaboration library via 3-way xml merging and hg dvcs under the hood.
SIL.ChorusPlugin.LibFLExBridge

Library that allows multiple FieldWorks users to collaborate remotely (i.e., not necessarily connected by a local network).
SIL.ChorusPlugin.LfMergeBridge

Library that allows multiple FieldWorks users to collaborate remotely (i.e., not necessarily connected by a local network).

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
8.0.0 0 3/12/2025
8.0.0-beta0023 0 3/12/2025
8.0.0-beta0021 0 3/12/2025
8.0.0-beta0013 221 3/7/2025
8.0.0-beta0005 2,448 6/4/2024
8.0.0-beta0004 92 5/10/2024
8.0.0-beta0003 239 4/19/2024
7.0.1-beta0001 108 4/15/2024
7.0.0 3,083 11/6/2023
7.0.0-beta0013 481 11/3/2023
7.0.0-beta0011 897 3/17/2023
7.0.0-beta0010 709 3/13/2023
6.1.0-beta0009 675 3/13/2023
6.1.0-beta0008 661 12/9/2022
6.1.0-beta0007 657 12/9/2022
6.0.1-beta0002 658 11/23/2022
6.0.0 15,721 11/23/2022
6.0.0-beta0018 623 11/21/2022
6.0.0-beta0017 671 10/7/2022
6.0.0-beta0015 671 8/24/2022
6.0.0-beta0013 663 8/24/2022
6.0.0-beta0003 707 7/12/2022
5.0.0 5,201 7/8/2022
5.0.0-beta0098 711 7/8/2022
5.0.0-beta0097 729 7/8/2022
5.0.0-beta0094 1,257 6/2/2022
5.0.0-beta0092 722 5/31/2022
5.0.0-beta0090 1,009 5/19/2022
5.0.0-beta0088 1,346 5/17/2022
5.0.0-beta0086 1,129 4/12/2022
5.0.0-beta0082 735 4/11/2022
5.0.0-beta0080 984 3/9/2022
5.0.0-beta0059 1,998 2/4/2022
5.0.0-beta.77 146 2/21/2022
5.0.0-beta.75 157 2/4/2022
4.2.0-beta0006 2,194 8/20/2021
4.2.0-beta0004 1,474 5/14/2021
4.1.1-beta0002 1,052 4/14/2021
4.1.0 13,835 3/4/2021
4.0.3 1,387 1/21/2020
4.0.2 1,486 7/9/2019
4.0.1 1,240 7/8/2019
4.0.0 1,700 5/16/2019

Changes since version 7.0.0

Changed:
-   BREAKING CHANGE: If no `LocalizationManager`s have been created, but the client asks for a string to be localized, an `InvalidOperationException` is thrown. This is to prevent an invalid state where language IDs get mapped incorrectly at the beginning and then never get updated which can cause us to fail to return properly localized strings when requested (see BL-13245). This is a breaking change because it may cause existing code to throw an exception. The fix is to ensure that a LocalizationManager is created before calling any localization methods. Or, to maintain existing behavior, set `LocalizationManager.StrictInitializationMode` to false.
-   BREAKING CHANGE: Changed the signature of StringExtractor.DoExtractingWork to return an IReadOnlyList instead of an IEnumerable. It is doubtful that anything outside L10nSharp is actually using this, but it is a breaking change because it may cause existing code to fail to compile. The fix is to change the type of the variable that receives the return value to IReadOnlyList.
 - Reduced the number of different types of exceptions likely to be thrown as a result of passing an invalid appVersion to the XLiffLocalizationManager constructor. Now, if the appVersion is invalid, an ArgumentException is thrown and the original exception from the call to Version.Parse is the internal exception. This is a technically a breaking change because if any existing code was catching the more specific exception types, the logic would need to be changed to catch only the ArgumentException and then do more specific processing based on the type of the inner exception. But since the details of the typesof exceptions was never explicitly documented and since applications would not be likely to be able to recover from such exceptions, it's probably very unlikely that any code was actually handling these exceptions in this way.

See full changelog at https://github.com/sillsdev/l10nsharp/blob/master/CHANGELOG.md