Handle empty TranslationInfo tag properly when parsing Settings.xml

[pmachapman]

Fixes #401.

I tested by modifying the Settings.xml file manually. If you think this should have its own test, we will need another test project in the file system, as none of the file system calls go through an abstraction layer.

---

This change is 

[codecov-commenter]

Codecov Report

❌ Patch coverage is 50.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.02%. Comparing base (812aa48) to head (deb7e5f).

Files with missing lines	Patch %	Lines
...chine/Corpora/ParatextProjectSettingsParserBase.cs	50.00%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #402      +/-   ##
==========================================
+ Coverage   73.00%   73.02%   +0.01%     
==========================================
  Files         439      439              
  Lines       36693    36693              
  Branches     5038     5039       +1     
==========================================
+ Hits        26789    26794       +5     
+ Misses       8789     8787       -2     
+ Partials     1115     1112       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ddaspit]

I think it would be helpful to have a test fixture for ParatextProjectSettingsParserBase to test this kind of logic. We can create a memory-based implementation for testing purposes. MemoryParatextProjectFileHandler already exists.

@ddaspit reviewed 1 file and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on Enkidu93).

[Enkidu93]

@Enkidu93 reviewed 1 file and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on pmachapman).

[pmachapman]

I think it would be helpful to have a test fixture for ParatextProjectSettingsParserBase to test this kind of logic. We can create a memory-based implementation for testing purposes. MemoryParatextProjectFileHandler already exists.

Thanks - done.

@pmachapman made 1 comment.
Reviewable status: 1 of 4 files reviewed, all discussions resolved (waiting on ddaspit and Enkidu93).

[Enkidu93]

@Enkidu93 reviewed 3 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on pmachapman).

---

tests/SIL.Machine.Tests/Corpora/MemoryParatextProjectFileHandler.cs line 14 at r2 (raw file):

        if (fileName is "usfm.sty" or "usfm_sb.sty")
            return new UsfmStylesheet(fileName);
        throw new NotImplementedException();

Is it better do you think to throw a NotSupportedException() here now?

[pmachapman]

@pmachapman made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on Enkidu93).

---

tests/SIL.Machine.Tests/Corpora/MemoryParatextProjectFileHandler.cs line 14 at r2 (raw file):

Previously, Enkidu93 (Eli C. Lowry) wrote…

Is it better do you think to throw a NotSupportedException() here now?

Semantically a NotSupportedException is the right choice, however looking over the code, NotImplementedException is the exception used in cases such as this. I think it is OK to keep it as-is for consistency's sake, but if you feel strongly about it, I can change it.

[Enkidu93]

@Enkidu93 made 1 comment and resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on pmachapman).

---

tests/SIL.Machine.Tests/Corpora/MemoryParatextProjectFileHandler.cs line 14 at r2 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

Semantically a NotSupportedException is the right choice, however looking over the code, NotImplementedException is the exception used in cases such as this. I think it is OK to keep it as-is for consistency's sake, but if you feel strongly about it, I can change it.

I see. Searching the code base, it looks like we use both (e.g. in FeatureModel we use not supported). Many of the existing NotImplementedExceptions look like remnants of my work. I'm fine with leaving it as-is, but I think you're also welcome to just update to using NotSupportedException in these instances if you like.

[ddaspit]

@ddaspit reviewed 3 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on pmachapman).