proposed change to UDF '_StringTitleCase()'

[iCode]

currently it looks like this...

; #FUNCTION# ====================================================================================================================
; Author ........: BrewManNH
; Modified ......:
; ===============================================================================================================================
Func _StringTitleCase($sString)
    Local $fCapNext = True, $sChr = "", $sReturn = ""
    For $i = 1 To StringLen($sString)
        $sChr = StringMid($sString, $i, 1)
        Select
            Case $fCapNext = True
                If StringRegExp($sChr, "[a-zA-Z\xC0-\xFF0-9]") Then
                    $sChr = StringUpper($sChr)
                    $fCapNext = False
                EndIf
            Case Not StringRegExp($sChr, "[a-zA-Z\xC0-\xFF'0-9]")
                $fCapNext = True
            Case Else
                $sChr = StringLower($sChr)
        EndSelect
        $sReturn &= $sChr
    Next
    Return $sReturn
EndFunc   ;==>_StringTitleCase

i am NO expert on RegEx, but there is a problem with the above line...

Case Not StringRegExp($sChr, "[a-zA-Z\xC0-\xFF'0-9]")

that will cause: 's (as in: that's) to become: 'S when the apostrophe is hex 2019:

’

suggested change is to simply add the missing char to the group, and possibly (*UCP)?:

Case Not StringRegExp($sChr, "(*UCP)[a-zA-Z\xC0-\xFF0-9'’]")

[DatMCEyeBall]

Hey!

Look, no replies!

Maybe if I reply then someone will do the same.

[guinness]

No, I saw way before the reply.

I think the change would be to add the hex value instead. Though I would need a guru of SRE to confirm the fix.

[DatMCEyeBall]

But you replied after the reply.

So, it works.

[jchd]

UCP isn't required for this to work. Reminder: UCP is Unicode Character Properties and we don't rely on any property there. Beta (hence next release) has UCP support built-in, but v3.3.8.1 lacks it.

Placing the apostrophe in the character class is fine (requires UTF8 source file). Only catch if you want to make that universal (hint: you can't) is that different apostrophes are used depending on language. Also your "fix" will now turn O’Connor into O’connor.

[guinness]

I am still not keen on adding the apostrophe directly, as I guess most encode as ANSI.

Edit: Maybe I use ChrW()?

Edited November 18, 2013 by guinness

[trancexx]

It's imposible to create unique rule that would produce the correct (expected) result for this function. For that reason function like this shouldn't exist at all as official UDF, at least not without disclaimer.

AutoIt doesn't force the use of any particular language for the users. The rules of AutoIt language syntax nor the rules of English language can't be applied to strings this function accepts. Even if you say _StringTitleCase accepts and processes only English words it would be impossible to create correct output without consulting both dictionary and specific grammar rules. Plus, both syntax and semantics dictates output. Best examples of that are the apostrophes, acronyms or ten other things that could be listed without thinking much. If you pass French sentence or Spanish or Portuguese, not to mention possibility of hundreds of other languages, you get mess. 

So either keep the algorithm very simple (Title-case) and add disclaimer to the help file or remove the damn function.

I think it's clear what I would do.

Edited November 18, 2013 by trancexx

[czardas]

So either keep the algorithm very simple (Title-case) and add disclaimer to the help file or remove the damn function.

I think it's clear what I would do.

 

  Keep it simple means include common British English (Associated Press) lower case exceptions.

;

a, an, and, as, at, but, by, for, from, in, into, nor, of, on, onto, or, per, so, the, to, up, via, with, yet

;

I believe this is the main set but there may also be more.

Edited November 18, 2013 by czardas

[iCode]

@DatMCEyeBall - i think you started an avalanche

my script is ANSI and i added the apostrophe without encoding it and it works perfectly

i agree that UCP doesn't need to be enabled for the EN language, but i thought that since the expression has a group with "a-zA-Z" in it, and UCP affects that, that it may be the safer thing to do?

i'm really not sure however since i'm no expert with RegEx and certainly no expert with Unicode!

[czardas]

'Ow 'Bout Lancashire Accent? - 't's Broke!

There are no clearly defined rules that everyone can agree on. The above would be acceptable in an English publication. I'm in agreement with trancexx on this one.

Edited November 18, 2013 by czardas

[iCode]

somebody told me that, decades ago, there was talk of a universal language... WHERE THE HELL IS IT!

[czardas]

http://en.wikipedia.org/wiki/Esperanto

[iCode]

100,000 - 2,000,000 speakers - doesn't look too "universal", does it

that name does ring a bell though

[BrewManNH]

It's imposible to create unique rule that would produce the correct (expected) result for this function. For that reason function like this shouldn't exist at all as official UDF, at least not without disclaimer.

Remarks

This function will capitalize the first character of every word. Does not support unicode strings.

It already does have a disclaimer.

Without a thousand page document to look up any possible variation of usage of apostrophes, there's no way a single function could ever create a perfect title cased sentence (and this isn't truly a title case function, it's actually a Start Case function). This produces a lot better output than the older _StringProper function that's been in the String UDF for years though.

[iCode]

It already does have a disclaimer.

Without a thousand page document to look up any possible variation of usage of apostrophes, there's no way a single function could ever create a perfect title cased sentence (and this isn't truly a title case function, it's actually a Start Case function). This produces a lot better output than the older _StringProper function that's been in the String UDF for years though.

good point, and because of that disclaimer and lack of support for unicode, i believe that strengthens my argument to incorporate the second type of apostrophe - it already has one and so the second is just another type of the first

sorry if i overstepped my bounds, i know this is a dev forum, and so i'll go away now

[jchd]

my script is ANSI and i added the apostrophe without encoding it and it works perfectly

Then you're not using the Unicode character U+2019 as you pretend you do, but its ANSI counterpart (e.g. 0x92 in Windows Western charset). That only works on ANSI input.

i agree that UCP doesn't need to be enabled for the EN language, but i thought that since the expression has a group with "a-zA-Z" in it, and UCP affects that, that it may be the safer thing to do?

Again, UCP doesn't "affect that" at all.

  Keep it simple means include common British English (Associated Press) lower case exceptions.

Simple shouldn't mean UK-centric!

It already does have a disclaimer.

That disclaimer is non-sensical. Every AutoIt string is Unicode. The disclaimer should mention "unaccentuated latin" or something like that.

good point, and because of that disclaimer and lack of support for unicode, i believe that strengthens my argument to incorporate the second type of apostrophe - it already has one and so the second is just another type of the first

sorry if i overstepped my bounds, i know this is a dev forum, and so i'll go away now

The question is not bounds, allowance, clearance but rather pragmatic thinking.

But in substance, what you say here is:

because lack of unaccentuated latin support (see remark above about Unicode) that you want to overcome, you propose to add an apostrophe character representation which will only work with ANSI input using one of the few Windows charsets which map this apostrophe to 0x92 ANSI?

It doesn't work much better the other way round: add support for the Unicode representation of apostrophe to overcome lack of "Unicode support".

Mind you, there are much more people using accentuated latin scripts (here script means written language) than people using english letters only. So if we want to cover the majority, we'd rather support a whole bunch of complex, contradictory rules to please this Babel. The problem is that we just can't.

[czardas]

Simple shouldn't mean UK-centric!

It was a joke.

[jchd]

My comment was as well!