Multi Rename feature does not take into consideration the "quote" sign
Posted: 18.09.2020, 12:53
After selecting files and pressing CTRL+M the window for Multi-Rename option appears
After choosing
Settings > Case > First letter of each word uppercase, extension lowercase
the use can change e.g.
into
But if the same example is a little more complex like
then the user ends up with
So the issue is hat first of the two
signs in the filename, which are posing for one
sign [because >> " << is an illegal character], would be apparently counted by the algorithm as the first letter thus preventing the Multi-Rename feature from changing
into correct
producing only a half correct form
But what is interesting, if the user would run this on
the user would end up with
which would be A-OK. So this would suggest that it is a bug that manifests itself only with some of the non-letter characters
In other words: the description of the options says "first letter of each word" while in reality it is merely the first sign- but not not always. Ans as quotes signs [or to be precise: their equivalents] are to be expected to appear in filenames- so this bug / inconsistency should be fixed
I am using Build 810a 32-bit public on Windows 10 Enterprise x64 18362.535
After choosing
Settings > Case > First letter of each word uppercase, extension lowercase
the use can change e.g.
Code: Select all
a sample sentence FOR the purpose of This topic
Code: Select all
A Sample Sentence For The Purpose Of This Topic
Code: Select all
a sample sentence ''FOR'' the purpose of This topic
Code: Select all
A Sample Sentence ''for'' The Purpose Of This Topic
So the issue is hat first of the two
Code: Select all
'
Code: Select all
"
Code: Select all
FOR
Code: Select all
For
Code: Select all
for
But what is interesting, if the user would run this on
Code: Select all
a sample sentence #FOR the purpose of This topic
Code: Select all
A Sample Sentence #For The Purpose Of This Topic
In other words: the description of the options says "first letter of each word" while in reality it is merely the first sign- but not not always. Ans as quotes signs [or to be precise: their equivalents] are to be expected to appear in filenames- so this bug / inconsistency should be fixed
I am using Build 810a 32-bit public on Windows 10 Enterprise x64 18362.535