Titlelize returns empty if text contains no known letters

[alowdon]

This might be by design, because this is not necessarily appropriate input, but if you try the following, for example:

"Майк".Titleize()
"@@".Titleize()

then it will throw an InvalidOperationException:

System.InvalidOperationException : Sequence contains no elements
   at System.Linq.Enumerable.Aggregate(IEnumerable`1 source, Func`3 func)
   at Humanizer.StringHumanizeExtensions.FromPascalCase(String input) in c:\TeamCity\buildAgent\work\8b6380f423671986\src\Humanizer\StringHumanizeExtensions.cs: line 32
   at Humanizer.StringHumanizeExtensions.Humanize(String input) in c:\TeamCity\buildAgent\work\8b6380f423671986\src\Humanizer\StringHumanizeExtensions.cs: line 64
   at Humanizer.StringHumanizeExtensions.Humanize(String input, LetterCasing casing) in c:\TeamCity\buildAgent\work\8b6380f423671986\src\Humanizer\StringHumanizeExtensions.cs: line 75
   at Humanizer.InflectorExtensions.Titleize(String input) in c:\TeamCity\buildAgent\work\8b6380f423671986\src\Humanizer\InflectorExtensions.cs: line 269

I would expect it to either throw a more relevant exception, or just to return the original input?

(P.S. Humanizer is a great library - thanks for producing and maintaining it!)

[MehdiK]

Thanks for reporting this Adrian.

This is not by design; it's a bug.

Did you want to send a PR? :)
On 24/02/2015 11:12 PM, "Adrian Lowdon" [email protected] wrote:

This might be by design, because this is not necessarily appropriate
input, but if you try the following, for example:

"Майк".Titleize()
"@@".Titleize()

then it will throw an InvalidOperationException:

System.InvalidOperationException : Sequence contains no elements
at System.Linq.Enumerable.Aggregate(IEnumerable1 source, Func3 func)
at Humanizer.StringHumanizeExtensions.FromPascalCase(String input) in c:\TeamCity\buildAgent\work\8b6380f423671986\src\Humanizer\StringHumanizeExtensions.cs: line 32
at Humanizer.StringHumanizeExtensions.Humanize(String input) in c:\TeamCity\buildAgent\work\8b6380f423671986\src\Humanizer\StringHumanizeExtensions.cs: line 64
at Humanizer.StringHumanizeExtensions.Humanize(String input, LetterCasing casing) in c:\TeamCity\buildAgent\work\8b6380f423671986\src\Humanizer\StringHumanizeExtensions.cs: line 75
at Humanizer.InflectorExtensions.Titleize(String input) in c:\TeamCity\buildAgent\work\8b6380f423671986\src\Humanizer\InflectorExtensions.cs: line 269

I would expect it to throw either a more relevant exception, or just to
return the original input?

(P.S. Humanizer is a great library - thanks for producing and maintaining
it!)

—
Reply to this email directly or view it on GitHub
#385.

[alowdon]

Thanks Mehdi - if I get chance I'll try to have a look!

[cusmonaut]

Hello, I am unable to reproduce the InvalidOperationException even with the examples given it just returns an empty string. Is this still an issue and if so is returning an empty string the desired behavior?

[alowdon]

I've just updated to v1.34.0 - it no longer throws the exception, but I'm not convinced that returning an empty string is the desired behaviour, personally I would expect it to return the original string if it can't process it?

[cusmonaut]

I agree, returning an empty string feels like data lose. I think we should always try to save as much information as we can in a situation like this.

[MehdiK]

Thanks for double checking this @alowdon. I have changed the title of the issue accordingly.

I agree that this is not desired behavior; but we will have to maintain this behavior for the existing users as what might look like a bug to us might be an expected behavior to them and I don't want to introduce a bug for some users by fixing a bug for others.

I have flagged this to be fixed as part of V2 which will include breaking changes. Until then you could wrap this with your own API and make it behave!

[cusmonaut]

@MehdiK If I were to fix this bug should I just do a pull request and comment it as for V2? Or is there a repo for V2?

[MehdiK]

@cusmonaut a separate repo would diverge from this one very quickly and so does a PR that stays here for a while.

The only way to have this now would be to add an optional parameter to the method that indicates what should happen to special and non-ascii characters defaulting to the current approach. Something like:

public static class Titlize
{
  public static ITitlizeStrategy DropSpecialChars = new TitlizeDropSpecialChars();
}

string Titlize(this string input, ITitlizeStrategy strategy = Titlize.DropSpecialChars)

[bahadirarslan]

Hi,

Titlize have some problems with non standart chars. For example there dotless and dotted i letter and this cause some problems.

Consider a text which contains dotless small i letter in it, like "kadın sesi" (which means "woman voice" in english btw)
So if you titlize it with Humanizer "kadın sesi".Titlize() the result will be like this "Kad N Sesi"
Or if you titlize word "Yönetici", which means manager in english", the result will be like "Netici"

[MehdiK]

On a second thought, due to this bug, I don't think anyone's using Titlize for non-English words. So it should be safe to fix this as part of V1 with no backward compatibility.

[jeremysimmons]

This bug is in StringHumanizeExtensions:FromPascalCase(string input) string
PascalCaseWordPartsRegex causes strings like "Майк" and "@@" to become whitespace.
Did you ever experiment with TextInfo.ToTitleCase?

[chris03]

I don't think anyone's using Titlize for non-English words

I'm using Humanize(LetterCasing.Title) to format the name of our clients and a lot of them have french names with accents (i.e. Stéphanie, François). It's kind of lame that these simple characters with accents disappear when they go trough Humanizer.

I found a workaround by calling Humanizer.To.TitleCase.Transform(""); I get the expected output.

[MehdiK]

Thanks for the input @chris03. That's actually a perfect use case and proves my assumption completely wrong.

Again I think we should fix the bug. We accept PRs too :)

[clairernovotny]

@jeremysimmons Any chance you could take a stab at fixing that RegEx?

[jeremysimmons]

@onovotny I'll take a peek. Thank you for asking. Why aren't we just using TextInfo.ToTitleCase http://referencesource.microsoft.com/#mscorlib/system/globalization/textinfo.cs,706 for this?
It works on all the test cases mentioned above...
@@ -> @@
kadın sesi -> Kadın Sesi
yönetici -> Yönetici
stéphanie -> Stéphanie
françois -> François
mайк -> Mайк

[jeremysimmons]

@onovotny this is a portable assembly. TextInfo.ToTitleCase isn't available in portable assemblies.

[jeremysimmons]

and. wow. that was rather painless.

old and busted.

new hotness.

too bad it breaks other unit tests...

[jeremysimmons]

@onovotny this is a working regex you can plug into PascalCaseWordPartsRegex in StringHumanizeExtensions.

PascalCaseWordPartsRegex = new Regex(@"\p{Lu}?\p{Ll}+|[0-9]+|\p{Lu}+(?=\p{Lu}\p{Ll}|[0-9]|\b)",

Does not work with @@ -> @@, still produces @@ -> String.Empty.
Works with all the other cases though, and no failing unit tests.

This should work for users that have a language that characters outside basic Latin.

I would have done a pull request, but I'm having some issues getting the dev branch working locally.

[jeremysimmons]

@MehdiK @onovotny Any opinion on whether the proposed regex above will work? Are we ok not supporting strings that are entirely symbols (@, ?, &, etc) for now?

[mexx]

IMHO any unrecognized characters should be left as is.

[MehdiK]

I'm with @mexx.