Quantcast

[Tiki-devel] Pref name capitalization

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Tiki-devel] Pref name capitalization

lindon-4
Yes, title-case is the other direction we could go. But remember we have pref names that are almost sentences, like the following:

"Minimum posts required before the thread configuration bar is displayed"

Probably most of the pref names are at least a short phrase, which will generally read a little better with normal capitalization.

Also the titles for the sections of the control panel pages (<legend>) typically use normal capitalization (some of which I converted, but many were that way already). To me we’d need to convert those too since they are at a higher level than the pref labels.

I did leave the tab titles with title-case, and also the plugin names, since they seemed like titles, but could go either way on those.

If, instead of considering pref names title-case, we instead say that certain features are proper nouns, then it gets really complicated and would result in a lot of work since that would mean we should be capitalizing the feature name every time it is used. For example, on the blogs control panel page the blog feature is referenced a number of times in pref names ("Home blog", "Custom blog headings”, etc.) as well as in descriptions. Arguably all of these are referring to the feature, not to blogs generically, and so would need to be capitalized. We could make a rule that only certain feature names should always be capitalized, but that would be arbitrary and likely get messy again over time as what is common versus unique changes.

Just wanted to give an idea of what I was thinking when I made the change. I still think normal capitalization is the best route, but of course would accept the consensus.
Regards,
lindon


On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]> wrote:


Tee hee, thanks Lindon, sorry for the pressure ;)

I'm as guilty as anyone about mixing things in commits but we should strive to make each one as "atomic" as possible i think.

Re the capitalisation inconsistency of things like Blogs or Articles which as Tiki features but also "common" nouns i agree it would be hard to tell, which is why i suggested "title-case" for all pref names, but that is unfortunately exactly the opposite of what you did in r62023 :P

I guess we should discuss (on the dev list)?

However, i'm really really going to do the branch now! :D

jb



On 2 Apr 2017, at 14:52, lindon <[hidden email]> wrote:

Wasn’t discussed and should have been, apologies for that. I’m happy to fix to whatever’s agreed to, so wouldn’t worry about the ultimate release.

Preference names were mixed on capitalization, including for things that one could easily consider proper nouns, so opted to conform in the direction of lower case given they are mostly used as labels. In my experience going the other way becomes very subjective and leads to a proliferation of inconsistent capitalization. For example, think of blogs (or Blogs). This is as proper a noun as Tiki Connect and yet it is more often than not written in lower case in the preference labels (and elsewhere) unless it’s the first word in a label. There a lots of examples like this so it struck me as difficult to come up with a logic that wouldn’t wind being arbitrary and hard to maintain. Anyway, that’s the reason I went the direction I did.

I understand the atomic commit point, but when doing basically REF cleanup on a series of files it doesn’t really make sense to me to try to anticipate how your changes should be parsed in case there is an objection. And going through the files multiple times to do each layer is really time-consuming. Having said that, I would have normally done a few files at a time except that I was sweating a 12-hour deadline :)
Regards,
lindon



On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]> wrote:

Hi Lindon and devs

Once again (same applies to r62021) there are several separate things going on in this commit and combing them together makes it hard to review what's going on... the part i'm not convinced about is not using title case for titles, like "Tiki Connect" being renamed to "Tiki connect" and "Daily Reports for User Watches" to "Daily reports for user watches" where Tiki Connect, Daily Reports, User Watches, File Galleries etc are all proper nouns as names for features in Tiki and so i believe at least they should be capitalised.

So the trouble is that if i roll this back the timeout warning improvements (and added units) will also be lost... we need to branch Tiki 17.x now and am short of time, as usual...

Was this discussed and agreed somewhere and i missed it? My feeling is that preference labels (that look like titles to me), should use title case, i.e. everything except conjunctions and indefinite articles should be capitalised, and should not use punctuation.

I wonder what to do now... i guess i have to branch now and we tidy it up in 17.x and trunk?

jonny


P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Gary Cunningham-Lee
Hi,

My opinion is that first-word-only capitalization makes the preference
lists (as on admin pages, etc.) look too generic, visually reducing the
significance of Tiki features. I think preference names that refer to
(that are the name of) a feature should use title capitalization
(https://en.wikipedia.org/wiki/Capitalization#Titles), as Tiki proper
nouns, but other preferences should use sentence capitalization (first
word and any contained proper nouns only are capitalized).

An informal test for this is if the term can be used in a phrase like
"the _____ feature", then it gets title-style capitalization; for
example, "the user watches feature" seems appropriate, so "User Watches"
is capitalized when referring to the feature.

Context plays a part, unfortunately, as title-style capitalization is
used when the term is used as a feature name, but the term isn't
capitalized otherwise. In practice, I don't think it's hard at all to
differentiate these cases (for example, in a string like "To post an
article, Articles must be activated") but it's not cut and dried either.

Long "almost-sentences" generally wouldn't get title-style
capitalization because it isn't correct to say "the Minimum posts
required before the thread configuration bar is displayed feature". A
more rational argument is that this type of preference seems to be a
detail or option within a larger preference rather than a standalone
feature, so phrase length isn't really the condition for capitalization.

Admittedly, there are subjective choices involved, to draw the line
between "feature" and "sub- (or non-)feature preference", but I think
most people would agree how to sort things. There are some edge-case
preferences that aren't clearly a "feature" or an option or detail of
one (like "CSS menus" on
tiki-admin.php?page=general#contentadmin_general-3), so maybe we could
just decide whether to be more formal or more casual generally, to sort
these cases accordingly.

Something related that's bothered me for a while is singular/plural
inconsistencies. It seems like the logic to make "Forums", "Articles"
and "Trackers" plural should also apply to Blogs, Calendars, Categories
and File Galleries, etc. (that is, in these cases the general content
area/type can have multiple distinct instances). This seems so
self-evident that I imagine it's just neglect that has caused the
situation to continue for so long. Or I guess mentally we just think
"Category feature" when we read "Category" in the feature list, etc.

I also can spend some time on making adjustments once we get a consensus.

-- Gary


On 4/3/2017 4:40 AM, lindon wrote:

> Yes, title-case is the other direction we could go. But remember we have
> pref names that are almost sentences, like the following:
>
> "Minimum posts required before the thread configuration bar is displayed"
>
> Probably most of the pref names are at least a short phrase, which will
> generally read a little better with normal capitalization.
>
> Also the titles for the sections of the control panel pages (<legend>)
> typically use normal capitalization (some of which I converted, but many
> were that way already). To me we’d need to convert those too since they
> are at a higher level than the pref labels.
>
> I did leave the tab titles with title-case, and also the plugin names,
> since they seemed like titles, but could go either way on those.
>
> If, instead of considering pref names title-case, we instead say that
> certain features are proper nouns, then it gets really complicated and
> would result in a lot of work since that would mean we should be
> capitalizing the feature name every time it is used. For example, on the
> blogs control panel page the blog feature is referenced a number of
> times in pref names ("Home blog", "Custom blog headings”, etc.) as well
> as in descriptions. Arguably all of these are referring to the feature,
> not to blogs generically, and so would need to be capitalized. We could
> make a rule that only certain feature names should always be
> capitalized, but that would be arbitrary and likely get messy again over
> time as what is common versus unique changes.
>
> Just wanted to give an idea of what I was thinking when I made the
> change. I still think normal capitalization is the best route, but of
> course would accept the consensus.
> Regards,
> lindon
>
>>
>>> On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>
>>> Tee hee, thanks Lindon, sorry for the pressure ;)
>>>
>>> I'm as guilty as anyone about mixing things in commits but we should
>>> strive to make each one as "atomic" as possible i think.
>>>
>>> Re the capitalisation inconsistency of things like Blogs or Articles
>>> which as Tiki features but also "common" nouns i agree it would be
>>> hard to tell, which is why i suggested "title-case" for all pref
>>> names, but that is unfortunately exactly the opposite of what you did
>>> in r62023 :P
>>>
>>> I guess we should discuss (on the dev list)?
>>>
>>> However, i'm really really going to do the branch now! :D
>>>
>>> jb
>>>
>>>
>>>
>>>> On 2 Apr 2017, at 14:52, lindon <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>> Wasn’t discussed and should have been, apologies for that. I’m happy
>>>> to fix to whatever’s agreed to, so wouldn’t worry about the ultimate
>>>> release.
>>>>
>>>> Preference names were mixed on capitalization, including for things
>>>> that one could easily consider proper nouns, so opted to conform in
>>>> the direction of lower case given they are mostly used as labels. In
>>>> my experience going the other way becomes very subjective and leads
>>>> to a proliferation of inconsistent capitalization. For example,
>>>> think of blogs (or Blogs). This is as proper a noun as Tiki Connect
>>>> and yet it is more often than not written in lower case in the
>>>> preference labels (and elsewhere) unless it’s the first word in a
>>>> label. There a lots of examples like this so it struck me as
>>>> difficult to come up with a logic that wouldn’t wind being arbitrary
>>>> and hard to maintain. Anyway, that’s the reason I went the direction
>>>> I did.
>>>>
>>>> I understand the atomic commit point, but when doing basically REF
>>>> cleanup on a series of files it doesn’t really make sense to me to
>>>> try to anticipate how your changes should be parsed in case there is
>>>> an objection. And going through the files multiple times to do each
>>>> layer is really time-consuming. Having said that, I would have
>>>> normally done a few files at a time except that I was sweating a
>>>> 12-hour deadline :)
>>>> Regards,
>>>> lindon
>>>>
>>>>
>>>>
>>>>> On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> Hi Lindon and devs
>>>>>
>>>>> Once again (same applies to r62021) there are several separate
>>>>> things going on in this commit and combing them together makes it
>>>>> hard to review what's going on... the part i'm not convinced about
>>>>> is not using title case for titles, like "Tiki Connect" being
>>>>> renamed to "Tiki connect" and "Daily Reports for User Watches" to
>>>>> "Daily reports for user watches" where Tiki Connect, Daily Reports,
>>>>> User Watches, File Galleries etc are all proper nouns as names for
>>>>> features in Tiki and so i believe at least they should be capitalised.
>>>>>
>>>>> So the trouble is that if i roll this back the timeout warning
>>>>> improvements (and added units) will also be lost... we need to
>>>>> branch Tiki 17.x now and am short of time, as usual...
>>>>>
>>>>> Was this discussed and agreed somewhere and i missed it? My feeling
>>>>> is that preference labels (that look like titles to me), should use
>>>>> title case, i.e. everything except conjunctions and indefinite
>>>>> articles should be capitalised, and should not use punctuation.
>>>>>
>>>>> I wonder what to do now... i guess i have to branch now and we tidy
>>>>> it up in 17.x and trunk?
>>>>>
>>>>> jonny
>>>>>
>>>>>
>>>>> P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)
>>>>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Brendan Ferguson
+1 to Gary

Brendan



On Apr 3, 2017, at 1:43 AM, Gary Cunningham-Lee <[hidden email]> wrote:

Hi,

My opinion is that first-word-only capitalization makes the preference 
lists (as on admin pages, etc.) look too generic, visually reducing the 
significance of Tiki features. I think preference names that refer to 
(that are the name of) a feature should use title capitalization 
(https://en.wikipedia.org/wiki/Capitalization#Titles), as Tiki proper 
nouns, but other preferences should use sentence capitalization (first 
word and any contained proper nouns only are capitalized).

An informal test for this is if the term can be used in a phrase like 
"the _____ feature", then it gets title-style capitalization; for 
example, "the user watches feature" seems appropriate, so "User Watches" 
is capitalized when referring to the feature.

Context plays a part, unfortunately, as title-style capitalization is 
used when the term is used as a feature name, but the term isn't 
capitalized otherwise. In practice, I don't think it's hard at all to 
differentiate these cases (for example, in a string like "To post an 
article, Articles must be activated") but it's not cut and dried either.

Long "almost-sentences" generally wouldn't get title-style 
capitalization because it isn't correct to say "the Minimum posts 
required before the thread configuration bar is displayed feature". A 
more rational argument is that this type of preference seems to be a 
detail or option within a larger preference rather than a standalone 
feature, so phrase length isn't really the condition for capitalization.

Admittedly, there are subjective choices involved, to draw the line 
between "feature" and "sub- (or non-)feature preference", but I think 
most people would agree how to sort things. There are some edge-case 
preferences that aren't clearly a "feature" or an option or detail of 
one (like "CSS menus" on 
tiki-admin.php?page=general#contentadmin_general-3), so maybe we could 
just decide whether to be more formal or more casual generally, to sort 
these cases accordingly.

Something related that's bothered me for a while is singular/plural 
inconsistencies. It seems like the logic to make "Forums", "Articles" 
and "Trackers" plural should also apply to Blogs, Calendars, Categories 
and File Galleries, etc. (that is, in these cases the general content 
area/type can have multiple distinct instances). This seems so 
self-evident that I imagine it's just neglect that has caused the 
situation to continue for so long. Or I guess mentally we just think 
"Category feature" when we read "Category" in the feature list, etc.

I also can spend some time on making adjustments once we get a consensus.

-- Gary


On 4/3/2017 4:40 AM, lindon wrote:
Yes, title-case is the other direction we could go. But remember we have
pref names that are almost sentences, like the following:

"Minimum posts required before the thread configuration bar is displayed"

Probably most of the pref names are at least a short phrase, which will
generally read a little better with normal capitalization.

Also the titles for the sections of the control panel pages (<legend>)
typically use normal capitalization (some of which I converted, but many
were that way already). To me we’d need to convert those too since they
are at a higher level than the pref labels.

I did leave the tab titles with title-case, and also the plugin names,
since they seemed like titles, but could go either way on those.

If, instead of considering pref names title-case, we instead say that
certain features are proper nouns, then it gets really complicated and
would result in a lot of work since that would mean we should be
capitalizing the feature name every time it is used. For example, on the
blogs control panel page the blog feature is referenced a number of
times in pref names ("Home blog", "Custom blog headings”, etc.) as well
as in descriptions. Arguably all of these are referring to the feature,
not to blogs generically, and so would need to be capitalized. We could
make a rule that only certain feature names should always be
capitalized, but that would be arbitrary and likely get messy again over
time as what is common versus unique changes.

Just wanted to give an idea of what I was thinking when I made the
change. I still think normal capitalization is the best route, but of
course would accept the consensus.
Regards,
lindon


On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]
<[hidden email]>> wrote:


Tee hee, thanks Lindon, sorry for the pressure ;)

I'm as guilty as anyone about mixing things in commits but we should
strive to make each one as "atomic" as possible i think.

Re the capitalisation inconsistency of things like Blogs or Articles
which as Tiki features but also "common" nouns i agree it would be
hard to tell, which is why i suggested "title-case" for all pref
names, but that is unfortunately exactly the opposite of what you did
in r62023 :P

I guess we should discuss (on the dev list)?

However, i'm really really going to do the branch now! :D

jb



On 2 Apr 2017, at 14:52, lindon <[hidden email]
<[hidden email]>> wrote:

Wasn’t discussed and should have been, apologies for that. I’m happy
to fix to whatever’s agreed to, so wouldn’t worry about the ultimate
release.

Preference names were mixed on capitalization, including for things
that one could easily consider proper nouns, so opted to conform in
the direction of lower case given they are mostly used as labels. In
my experience going the other way becomes very subjective and leads
to a proliferation of inconsistent capitalization. For example,
think of blogs (or Blogs). This is as proper a noun as Tiki Connect
and yet it is more often than not written in lower case in the
preference labels (and elsewhere) unless it’s the first word in a
label. There a lots of examples like this so it struck me as
difficult to come up with a logic that wouldn’t wind being arbitrary
and hard to maintain. Anyway, that’s the reason I went the direction
I did.

I understand the atomic commit point, but when doing basically REF
cleanup on a series of files it doesn’t really make sense to me to
try to anticipate how your changes should be parsed in case there is
an objection. And going through the files multiple times to do each
layer is really time-consuming. Having said that, I would have
normally done a few files at a time except that I was sweating a
12-hour deadline :)
Regards,
lindon



On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]
<[hidden email]>> wrote:

Hi Lindon and devs

Once again (same applies to r62021) there are several separate
things going on in this commit and combing them together makes it
hard to review what's going on... the part i'm not convinced about
is not using title case for titles, like "Tiki Connect" being
renamed to "Tiki connect" and "Daily Reports for User Watches" to
"Daily reports for user watches" where Tiki Connect, Daily Reports,
User Watches, File Galleries etc are all proper nouns as names for
features in Tiki and so i believe at least they should be capitalised.

So the trouble is that if i roll this back the timeout warning
improvements (and added units) will also be lost... we need to
branch Tiki 17.x now and am short of time, as usual...

Was this discussed and agreed somewhere and i missed it? My feeling
is that preference labels (that look like titles to me), should use
title case, i.e. everything except conjunctions and indefinite
articles should be capitalised, and should not use punctuation.

I wonder what to do now... i guess i have to branch now and we tidy
it up in 17.x and trunk?

jonny


P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Jonny Bradley-4
In reply to this post by lindon-4
Hi Lindon and all

> On 2 Apr 2017, at 20:40, lindon <[hidden email]> wrote:
>
> Yes, title-case is the other direction we could go. But remember we have pref names that are almost sentences, like the following:
>
>> "Minimum posts required before the thread configuration bar is displayed"

I reckon prefs like those need fixing - that;'s not a "name" (label or title), that should be the description or hint, and the name should be something like "Thread Configuration Minimum" (but what does it do? Seems like a rather niche pref that probably should have been done with CSS? ;)

> Probably most of the pref names are at least a short phrase, which will generally read a little better with normal capitalization.
>
> Also the titles for the sections of the control panel pages (<legend>) typically use normal capitalization (some of which I converted, but many were that way already). To me we’d need to convert those too since they are at a higher level than the pref labels.
>
> I did leave the tab titles with title-case, and also the plugin names, since they seemed like titles, but could go either way on those.
>
> If, instead of considering pref names title-case, we instead say that certain features are proper nouns, then it gets really complicated and would result in a lot of work since that would mean we should be capitalizing the feature name every time it is used. For example, on the blogs control panel page the blog feature is referenced a number of times in pref names ("Home blog", "Custom blog headings”, etc.) as well as in descriptions. Arguably all of these are referring to the feature, not to blogs generically, and so would need to be capitalized. We could make a rule that only certain feature names should always be capitalized, but that would be arbitrary and likely get messy again over time as what is common versus unique changes.
>
> Just wanted to give an idea of what I was thinking when I made the change. I still think normal capitalization is the best route, but of course would accept the consensus.

Exactly, if by "normal capitalization" you mean "title case"? As described here:

    https://en.wikipedia.org/wiki/Letter_case#Title_case

Thanks

jonny


> Regards,
> lindon
>
>>
>>> On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]> wrote:
>>>
>>>
>>> Tee hee, thanks Lindon, sorry for the pressure ;)
>>>
>>> I'm as guilty as anyone about mixing things in commits but we should strive to make each one as "atomic" as possible i think.
>>>
>>> Re the capitalisation inconsistency of things like Blogs or Articles which as Tiki features but also "common" nouns i agree it would be hard to tell, which is why i suggested "title-case" for all pref names, but that is unfortunately exactly the opposite of what you did in r62023 :P
>>>
>>> I guess we should discuss (on the dev list)?
>>>
>>> However, i'm really really going to do the branch now! :D
>>>
>>> jb
>>>
>>>
>>>
>>>> On 2 Apr 2017, at 14:52, lindon <[hidden email]> wrote:
>>>>
>>>> Wasn’t discussed and should have been, apologies for that. I’m happy to fix to whatever’s agreed to, so wouldn’t worry about the ultimate release.
>>>>
>>>> Preference names were mixed on capitalization, including for things that one could easily consider proper nouns, so opted to conform in the direction of lower case given they are mostly used as labels. In my experience going the other way becomes very subjective and leads to a proliferation of inconsistent capitalization. For example, think of blogs (or Blogs). This is as proper a noun as Tiki Connect and yet it is more often than not written in lower case in the preference labels (and elsewhere) unless it’s the first word in a label. There a lots of examples like this so it struck me as difficult to come up with a logic that wouldn’t wind being arbitrary and hard to maintain. Anyway, that’s the reason I went the direction I did.
>>>>
>>>> I understand the atomic commit point, but when doing basically REF cleanup on a series of files it doesn’t really make sense to me to try to anticipate how your changes should be parsed in case there is an objection. And going through the files multiple times to do each layer is really time-consuming. Having said that, I would have normally done a few files at a time except that I was sweating a 12-hour deadline :)
>>>> Regards,
>>>> lindon
>>>>
>>>>
>>>>
>>>>> On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]> wrote:
>>>>>
>>>>> Hi Lindon and devs
>>>>>
>>>>> Once again (same applies to r62021) there are several separate things going on in this commit and combing them together makes it hard to review what's going on... the part i'm not convinced about is not using title case for titles, like "Tiki Connect" being renamed to "Tiki connect" and "Daily Reports for User Watches" to "Daily reports for user watches" where Tiki Connect, Daily Reports, User Watches, File Galleries etc are all proper nouns as names for features in Tiki and so i believe at least they should be capitalised.
>>>>>
>>>>> So the trouble is that if i roll this back the timeout warning improvements (and added units) will also be lost... we need to branch Tiki 17.x now and am short of time, as usual...
>>>>>
>>>>> Was this discussed and agreed somewhere and i missed it? My feeling is that preference labels (that look like titles to me), should use title case, i.e. everything except conjunctions and indefinite articles should be capitalised, and should not use punctuation.
>>>>>
>>>>> I wonder what to do now... i guess i have to branch now and we tidy it up in 17.x and trunk?
>>>>>
>>>>> jonny
>>>>>
>>>>>
>>>>> P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)
>>>>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Jonny Bradley-4
In reply to this post by Gary Cunningham-Lee
Hi Gary++

I fear that this might be open to misinterpretation and a simpler rule would be preferable, like https://en.wikipedia.org/wiki/Capitalization#Titles or https://en.wikipedia.org/wiki/Letter_case#Title_case where we can point to a simple rule. Making it too Tiki-centric i think over complicates this...

Any 'Long "almost-sentences"' type names should be moved to the description and a "snappier" name invented where possible, and if that's hard maybe the  pref is ill conceived in the first please?

I agree about the singular vs plural thing though, let's converge on plurals for features like Calendars and Blogs, and Categories (as if we have Category then why not Tag and Poll just after it?)

However... Wiki vs Wikis? (only kidding, but there are always exceptions! ;)

Must get on... as you know i'm not normally that bothered about the contents of strings, so i'm sure i'll get used to whatever is decided!

jb



> On 3 Apr 2017, at 06:43, Gary Cunningham-Lee <[hidden email]> wrote:
>
> Hi,
>
> My opinion is that first-word-only capitalization makes the preference
> lists (as on admin pages, etc.) look too generic, visually reducing the
> significance of Tiki features. I think preference names that refer to
> (that are the name of) a feature should use title capitalization
> (https://en.wikipedia.org/wiki/Capitalization#Titles), as Tiki proper
> nouns, but other preferences should use sentence capitalization (first
> word and any contained proper nouns only are capitalized).
>
> An informal test for this is if the term can be used in a phrase like
> "the _____ feature", then it gets title-style capitalization; for
> example, "the user watches feature" seems appropriate, so "User Watches"
> is capitalized when referring to the feature.
>
> Context plays a part, unfortunately, as title-style capitalization is
> used when the term is used as a feature name, but the term isn't
> capitalized otherwise. In practice, I don't think it's hard at all to
> differentiate these cases (for example, in a string like "To post an
> article, Articles must be activated") but it's not cut and dried either.
>
> Long "almost-sentences" generally wouldn't get title-style
> capitalization because it isn't correct to say "the Minimum posts
> required before the thread configuration bar is displayed feature". A
> more rational argument is that this type of preference seems to be a
> detail or option within a larger preference rather than a standalone
> feature, so phrase length isn't really the condition for capitalization.
>
> Admittedly, there are subjective choices involved, to draw the line
> between "feature" and "sub- (or non-)feature preference", but I think
> most people would agree how to sort things. There are some edge-case
> preferences that aren't clearly a "feature" or an option or detail of
> one (like "CSS menus" on
> tiki-admin.php?page=general#contentadmin_general-3), so maybe we could
> just decide whether to be more formal or more casual generally, to sort
> these cases accordingly.
>
> Something related that's bothered me for a while is singular/plural
> inconsistencies. It seems like the logic to make "Forums", "Articles"
> and "Trackers" plural should also apply to Blogs, Calendars, Categories
> and File Galleries, etc. (that is, in these cases the general content
> area/type can have multiple distinct instances). This seems so
> self-evident that I imagine it's just neglect that has caused the
> situation to continue for so long. Or I guess mentally we just think
> "Category feature" when we read "Category" in the feature list, etc.
>
> I also can spend some time on making adjustments once we get a consensus.
>
> -- Gary
>
>
> On 4/3/2017 4:40 AM, lindon wrote:
>> Yes, title-case is the other direction we could go. But remember we have
>> pref names that are almost sentences, like the following:
>>
>> "Minimum posts required before the thread configuration bar is displayed"
>>
>> Probably most of the pref names are at least a short phrase, which will
>> generally read a little better with normal capitalization.
>>
>> Also the titles for the sections of the control panel pages (<legend>)
>> typically use normal capitalization (some of which I converted, but many
>> were that way already). To me we’d need to convert those too since they
>> are at a higher level than the pref labels.
>>
>> I did leave the tab titles with title-case, and also the plugin names,
>> since they seemed like titles, but could go either way on those.
>>
>> If, instead of considering pref names title-case, we instead say that
>> certain features are proper nouns, then it gets really complicated and
>> would result in a lot of work since that would mean we should be
>> capitalizing the feature name every time it is used. For example, on the
>> blogs control panel page the blog feature is referenced a number of
>> times in pref names ("Home blog", "Custom blog headings”, etc.) as well
>> as in descriptions. Arguably all of these are referring to the feature,
>> not to blogs generically, and so would need to be capitalized. We could
>> make a rule that only certain feature names should always be
>> capitalized, but that would be arbitrary and likely get messy again over
>> time as what is common versus unique changes.
>>
>> Just wanted to give an idea of what I was thinking when I made the
>> change. I still think normal capitalization is the best route, but of
>> course would accept the consensus.
>> Regards,
>> lindon
>>
>>>
>>>> On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>
>>>> Tee hee, thanks Lindon, sorry for the pressure ;)
>>>>
>>>> I'm as guilty as anyone about mixing things in commits but we should
>>>> strive to make each one as "atomic" as possible i think.
>>>>
>>>> Re the capitalisation inconsistency of things like Blogs or Articles
>>>> which as Tiki features but also "common" nouns i agree it would be
>>>> hard to tell, which is why i suggested "title-case" for all pref
>>>> names, but that is unfortunately exactly the opposite of what you did
>>>> in r62023 :P
>>>>
>>>> I guess we should discuss (on the dev list)?
>>>>
>>>> However, i'm really really going to do the branch now! :D
>>>>
>>>> jb
>>>>
>>>>
>>>>
>>>>> On 2 Apr 2017, at 14:52, lindon <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> Wasn’t discussed and should have been, apologies for that. I’m happy
>>>>> to fix to whatever’s agreed to, so wouldn’t worry about the ultimate
>>>>> release.
>>>>>
>>>>> Preference names were mixed on capitalization, including for things
>>>>> that one could easily consider proper nouns, so opted to conform in
>>>>> the direction of lower case given they are mostly used as labels. In
>>>>> my experience going the other way becomes very subjective and leads
>>>>> to a proliferation of inconsistent capitalization. For example,
>>>>> think of blogs (or Blogs). This is as proper a noun as Tiki Connect
>>>>> and yet it is more often than not written in lower case in the
>>>>> preference labels (and elsewhere) unless it’s the first word in a
>>>>> label. There a lots of examples like this so it struck me as
>>>>> difficult to come up with a logic that wouldn’t wind being arbitrary
>>>>> and hard to maintain. Anyway, that’s the reason I went the direction
>>>>> I did.
>>>>>
>>>>> I understand the atomic commit point, but when doing basically REF
>>>>> cleanup on a series of files it doesn’t really make sense to me to
>>>>> try to anticipate how your changes should be parsed in case there is
>>>>> an objection. And going through the files multiple times to do each
>>>>> layer is really time-consuming. Having said that, I would have
>>>>> normally done a few files at a time except that I was sweating a
>>>>> 12-hour deadline :)
>>>>> Regards,
>>>>> lindon
>>>>>
>>>>>
>>>>>
>>>>>> On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]
>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Hi Lindon and devs
>>>>>>
>>>>>> Once again (same applies to r62021) there are several separate
>>>>>> things going on in this commit and combing them together makes it
>>>>>> hard to review what's going on... the part i'm not convinced about
>>>>>> is not using title case for titles, like "Tiki Connect" being
>>>>>> renamed to "Tiki connect" and "Daily Reports for User Watches" to
>>>>>> "Daily reports for user watches" where Tiki Connect, Daily Reports,
>>>>>> User Watches, File Galleries etc are all proper nouns as names for
>>>>>> features in Tiki and so i believe at least they should be capitalised.
>>>>>>
>>>>>> So the trouble is that if i roll this back the timeout warning
>>>>>> improvements (and added units) will also be lost... we need to
>>>>>> branch Tiki 17.x now and am short of time, as usual...
>>>>>>
>>>>>> Was this discussed and agreed somewhere and i missed it? My feeling
>>>>>> is that preference labels (that look like titles to me), should use
>>>>>> title case, i.e. everything except conjunctions and indefinite
>>>>>> articles should be capitalised, and should not use punctuation.
>>>>>>
>>>>>> I wonder what to do now... i guess i have to branch now and we tidy
>>>>>> it up in 17.x and trunk?
>>>>>>
>>>>>> jonny
>>>>>>
>>>>>>
>>>>>> P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)
>>>>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Nagy Géza
my few cents about singular vs. plural: I prefer singular for feature
names (Wiki, Blog, Article, Category, etc), plural form is more about
referring to the recorded items (content list)

but I am fine with whatever the consensus is

cheers,

gezza


Nagy Géza

Ügyvezető/CEO
Oregional Kft./Ltd.
[hidden email]
oregional.hu

2017. 04. 03. 12:41 keltezéssel, Jonny Bradley írta:

> Hi Gary++
>
> I fear that this might be open to misinterpretation and a simpler rule would be preferable, like https://en.wikipedia.org/wiki/Capitalization#Titles or https://en.wikipedia.org/wiki/Letter_case#Title_case where we can point to a simple rule. Making it too Tiki-centric i think over complicates this...
>
> Any 'Long "almost-sentences"' type names should be moved to the description and a "snappier" name invented where possible, and if that's hard maybe the  pref is ill conceived in the first please?
>
> I agree about the singular vs plural thing though, let's converge on plurals for features like Calendars and Blogs, and Categories (as if we have Category then why not Tag and Poll just after it?)
>
> However... Wiki vs Wikis? (only kidding, but there are always exceptions! ;)
>
> Must get on... as you know i'm not normally that bothered about the contents of strings, so i'm sure i'll get used to whatever is decided!
>
> jb
>
>
>
>> On 3 Apr 2017, at 06:43, Gary Cunningham-Lee <[hidden email]> wrote:
>>
>> Hi,
>>
>> My opinion is that first-word-only capitalization makes the preference
>> lists (as on admin pages, etc.) look too generic, visually reducing the
>> significance of Tiki features. I think preference names that refer to
>> (that are the name of) a feature should use title capitalization
>> (https://en.wikipedia.org/wiki/Capitalization#Titles), as Tiki proper
>> nouns, but other preferences should use sentence capitalization (first
>> word and any contained proper nouns only are capitalized).
>>
>> An informal test for this is if the term can be used in a phrase like
>> "the _____ feature", then it gets title-style capitalization; for
>> example, "the user watches feature" seems appropriate, so "User Watches"
>> is capitalized when referring to the feature.
>>
>> Context plays a part, unfortunately, as title-style capitalization is
>> used when the term is used as a feature name, but the term isn't
>> capitalized otherwise. In practice, I don't think it's hard at all to
>> differentiate these cases (for example, in a string like "To post an
>> article, Articles must be activated") but it's not cut and dried either.
>>
>> Long "almost-sentences" generally wouldn't get title-style
>> capitalization because it isn't correct to say "the Minimum posts
>> required before the thread configuration bar is displayed feature". A
>> more rational argument is that this type of preference seems to be a
>> detail or option within a larger preference rather than a standalone
>> feature, so phrase length isn't really the condition for capitalization.
>>
>> Admittedly, there are subjective choices involved, to draw the line
>> between "feature" and "sub- (or non-)feature preference", but I think
>> most people would agree how to sort things. There are some edge-case
>> preferences that aren't clearly a "feature" or an option or detail of
>> one (like "CSS menus" on
>> tiki-admin.php?page=general#contentadmin_general-3), so maybe we could
>> just decide whether to be more formal or more casual generally, to sort
>> these cases accordingly.
>>
>> Something related that's bothered me for a while is singular/plural
>> inconsistencies. It seems like the logic to make "Forums", "Articles"
>> and "Trackers" plural should also apply to Blogs, Calendars, Categories
>> and File Galleries, etc. (that is, in these cases the general content
>> area/type can have multiple distinct instances). This seems so
>> self-evident that I imagine it's just neglect that has caused the
>> situation to continue for so long. Or I guess mentally we just think
>> "Category feature" when we read "Category" in the feature list, etc.
>>
>> I also can spend some time on making adjustments once we get a consensus.
>>
>> -- Gary
>>
>>
>> On 4/3/2017 4:40 AM, lindon wrote:
>>> Yes, title-case is the other direction we could go. But remember we have
>>> pref names that are almost sentences, like the following:
>>>
>>> "Minimum posts required before the thread configuration bar is displayed"
>>>
>>> Probably most of the pref names are at least a short phrase, which will
>>> generally read a little better with normal capitalization.
>>>
>>> Also the titles for the sections of the control panel pages (<legend>)
>>> typically use normal capitalization (some of which I converted, but many
>>> were that way already). To me we’d need to convert those too since they
>>> are at a higher level than the pref labels.
>>>
>>> I did leave the tab titles with title-case, and also the plugin names,
>>> since they seemed like titles, but could go either way on those.
>>>
>>> If, instead of considering pref names title-case, we instead say that
>>> certain features are proper nouns, then it gets really complicated and
>>> would result in a lot of work since that would mean we should be
>>> capitalizing the feature name every time it is used. For example, on the
>>> blogs control panel page the blog feature is referenced a number of
>>> times in pref names ("Home blog", "Custom blog headings”, etc.) as well
>>> as in descriptions. Arguably all of these are referring to the feature,
>>> not to blogs generically, and so would need to be capitalized. We could
>>> make a rule that only certain feature names should always be
>>> capitalized, but that would be arbitrary and likely get messy again over
>>> time as what is common versus unique changes.
>>>
>>> Just wanted to give an idea of what I was thinking when I made the
>>> change. I still think normal capitalization is the best route, but of
>>> course would accept the consensus.
>>> Regards,
>>> lindon
>>>
>>>>> On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>>
>>>>> Tee hee, thanks Lindon, sorry for the pressure ;)
>>>>>
>>>>> I'm as guilty as anyone about mixing things in commits but we should
>>>>> strive to make each one as "atomic" as possible i think.
>>>>>
>>>>> Re the capitalisation inconsistency of things like Blogs or Articles
>>>>> which as Tiki features but also "common" nouns i agree it would be
>>>>> hard to tell, which is why i suggested "title-case" for all pref
>>>>> names, but that is unfortunately exactly the opposite of what you did
>>>>> in r62023 :P
>>>>>
>>>>> I guess we should discuss (on the dev list)?
>>>>>
>>>>> However, i'm really really going to do the branch now! :D
>>>>>
>>>>> jb
>>>>>
>>>>>
>>>>>
>>>>>> On 2 Apr 2017, at 14:52, lindon <[hidden email]
>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Wasn’t discussed and should have been, apologies for that. I’m happy
>>>>>> to fix to whatever’s agreed to, so wouldn’t worry about the ultimate
>>>>>> release.
>>>>>>
>>>>>> Preference names were mixed on capitalization, including for things
>>>>>> that one could easily consider proper nouns, so opted to conform in
>>>>>> the direction of lower case given they are mostly used as labels. In
>>>>>> my experience going the other way becomes very subjective and leads
>>>>>> to a proliferation of inconsistent capitalization. For example,
>>>>>> think of blogs (or Blogs). This is as proper a noun as Tiki Connect
>>>>>> and yet it is more often than not written in lower case in the
>>>>>> preference labels (and elsewhere) unless it’s the first word in a
>>>>>> label. There a lots of examples like this so it struck me as
>>>>>> difficult to come up with a logic that wouldn’t wind being arbitrary
>>>>>> and hard to maintain. Anyway, that’s the reason I went the direction
>>>>>> I did.
>>>>>>
>>>>>> I understand the atomic commit point, but when doing basically REF
>>>>>> cleanup on a series of files it doesn’t really make sense to me to
>>>>>> try to anticipate how your changes should be parsed in case there is
>>>>>> an objection. And going through the files multiple times to do each
>>>>>> layer is really time-consuming. Having said that, I would have
>>>>>> normally done a few files at a time except that I was sweating a
>>>>>> 12-hour deadline :)
>>>>>> Regards,
>>>>>> lindon
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]
>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>> Hi Lindon and devs
>>>>>>>
>>>>>>> Once again (same applies to r62021) there are several separate
>>>>>>> things going on in this commit and combing them together makes it
>>>>>>> hard to review what's going on... the part i'm not convinced about
>>>>>>> is not using title case for titles, like "Tiki Connect" being
>>>>>>> renamed to "Tiki connect" and "Daily Reports for User Watches" to
>>>>>>> "Daily reports for user watches" where Tiki Connect, Daily Reports,
>>>>>>> User Watches, File Galleries etc are all proper nouns as names for
>>>>>>> features in Tiki and so i believe at least they should be capitalised.
>>>>>>>
>>>>>>> So the trouble is that if i roll this back the timeout warning
>>>>>>> improvements (and added units) will also be lost... we need to
>>>>>>> branch Tiki 17.x now and am short of time, as usual...
>>>>>>>
>>>>>>> Was this discussed and agreed somewhere and i missed it? My feeling
>>>>>>> is that preference labels (that look like titles to me), should use
>>>>>>> title case, i.e. everything except conjunctions and indefinite
>>>>>>> articles should be capitalised, and should not use punctuation.
>>>>>>>
>>>>>>> I wonder what to do now... i guess i have to branch now and we tidy
>>>>>>> it up in 17.x and trunk?
>>>>>>>
>>>>>>> jonny
>>>>>>>
>>>>>>>
>>>>>>> P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)
>>>>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>>
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


---
Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

lindon-4
In reply to this post by Jonny Bradley-4
I didn't mean title case when I said "normal" capitalization, I meant regular dictionary sentence capitalization.

But I agree it would be better to stick with either title case or sentence capitalization, and not have something in-between.

I also agree that to go for title case would mean shortening a lot (and I mean a lot!) of titles and even finding another solution for some of the niche ones as you mention.

Gary mentioned "edge cases" when describing his method - there's a lot of those as well. I'm sure whatever Gary would choose would be nice, but I share the fear that it would get too complicated.
Regards,
lindon

> On Apr 3, 2017, at 6:29 AM, Jonny Bradley <[hidden email]> wrote:
>
> Hi Lindon and all
>
>> On 2 Apr 2017, at 20:40, lindon <[hidden email]> wrote:
>>
>> Yes, title-case is the other direction we could go. But remember we have pref names that are almost sentences, like the following:
>>
>>> "Minimum posts required before the thread configuration bar is displayed"
>
> I reckon prefs like those need fixing - that;'s not a "name" (label or title), that should be the description or hint, and the name should be something like "Thread Configuration Minimum" (but what does it do? Seems like a rather niche pref that probably should have been done with CSS? ;)
>
>> Probably most of the pref names are at least a short phrase, which will generally read a little better with normal capitalization.
>>
>> Also the titles for the sections of the control panel pages (<legend>) typically use normal capitalization (some of which I converted, but many were that way already). To me we’d need to convert those too since they are at a higher level than the pref labels.
>>
>> I did leave the tab titles with title-case, and also the plugin names, since they seemed like titles, but could go either way on those.
>>
>> If, instead of considering pref names title-case, we instead say that certain features are proper nouns, then it gets really complicated and would result in a lot of work since that would mean we should be capitalizing the feature name every time it is used. For example, on the blogs control panel page the blog feature is referenced a number of times in pref names ("Home blog", "Custom blog headings”, etc.) as well as in descriptions. Arguably all of these are referring to the feature, not to blogs generically, and so would need to be capitalized. We could make a rule that only certain feature names should always be capitalized, but that would be arbitrary and likely get messy again over time as what is common versus unique changes.
>>
>> Just wanted to give an idea of what I was thinking when I made the change. I still think normal capitalization is the best route, but of course would accept the consensus.
>
> Exactly, if by "normal capitalization" you mean "title case"? As described here:
>
>    https://en.wikipedia.org/wiki/Letter_case#Title_case
>
> Thanks
>
> jonny
>
>
>> Regards,
>> lindon
>>
>>>
>>>> On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]> wrote:
>>>>
>>>>
>>>> Tee hee, thanks Lindon, sorry for the pressure ;)
>>>>
>>>> I'm as guilty as anyone about mixing things in commits but we should strive to make each one as "atomic" as possible i think.
>>>>
>>>> Re the capitalisation inconsistency of things like Blogs or Articles which as Tiki features but also "common" nouns i agree it would be hard to tell, which is why i suggested "title-case" for all pref names, but that is unfortunately exactly the opposite of what you did in r62023 :P
>>>>
>>>> I guess we should discuss (on the dev list)?
>>>>
>>>> However, i'm really really going to do the branch now! :D
>>>>
>>>> jb
>>>>
>>>>
>>>>
>>>>> On 2 Apr 2017, at 14:52, lindon <[hidden email]> wrote:
>>>>>
>>>>> Wasn’t discussed and should have been, apologies for that. I’m happy to fix to whatever’s agreed to, so wouldn’t worry about the ultimate release.
>>>>>
>>>>> Preference names were mixed on capitalization, including for things that one could easily consider proper nouns, so opted to conform in the direction of lower case given they are mostly used as labels. In my experience going the other way becomes very subjective and leads to a proliferation of inconsistent capitalization. For example, think of blogs (or Blogs). This is as proper a noun as Tiki Connect and yet it is more often than not written in lower case in the preference labels (and elsewhere) unless it’s the first word in a label. There a lots of examples like this so it struck me as difficult to come up with a logic that wouldn’t wind being arbitrary and hard to maintain. Anyway, that’s the reason I went the direction I did.
>>>>>
>>>>> I understand the atomic commit point, but when doing basically REF cleanup on a series of files it doesn’t really make sense to me to try to anticipate how your changes should be parsed in case there is an objection. And going through the files multiple times to do each layer is really time-consuming. Having said that, I would have normally done a few files at a time except that I was sweating a 12-hour deadline :)
>>>>> Regards,
>>>>> lindon
>>>>>
>>>>>
>>>>>
>>>>>> On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Lindon and devs
>>>>>>
>>>>>> Once again (same applies to r62021) there are several separate things going on in this commit and combing them together makes it hard to review what's going on... the part i'm not convinced about is not using title case for titles, like "Tiki Connect" being renamed to "Tiki connect" and "Daily Reports for User Watches" to "Daily reports for user watches" where Tiki Connect, Daily Reports, User Watches, File Galleries etc are all proper nouns as names for features in Tiki and so i believe at least they should be capitalised.
>>>>>>
>>>>>> So the trouble is that if i roll this back the timeout warning improvements (and added units) will also be lost... we need to branch Tiki 17.x now and am short of time, as usual...
>>>>>>
>>>>>> Was this discussed and agreed somewhere and i missed it? My feeling is that preference labels (that look like titles to me), should use title case, i.e. everything except conjunctions and indefinite articles should be capitalised, and should not use punctuation.
>>>>>>
>>>>>> I wonder what to do now... i guess i have to branch now and we tidy it up in 17.x and trunk?
>>>>>>
>>>>>> jonny
>>>>>>
>>>>>>
>>>>>> P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)
>>>>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Torsten Fabricius-4
In reply to this post by Nagy Géza
+1

On 03.04.2017 13:36, Nagy Géza wrote:

> my few cents about singular vs. plural: I prefer singular for feature
> names (Wiki, Blog, Article, Category, etc), plural form is more about
> referring to the recorded items (content list)
>
> but I am fine with whatever the consensus is
>
> cheers,
>
> gezza
>
>
> Nagy Géza
>
> Ügyvezető/CEO
> Oregional Kft./Ltd.
> [hidden email]
> oregional.hu
>
> 2017. 04. 03. 12:41 keltezéssel, Jonny Bradley írta:
>> Hi Gary++
>>
>> I fear that this might be open to misinterpretation and a simpler rule would be preferable, like https://en.wikipedia.org/wiki/Capitalization#Titles or https://en.wikipedia.org/wiki/Letter_case#Title_case where we can point to a simple rule. Making it too Tiki-centric i think over complicates this...
>>
>> Any 'Long "almost-sentences"' type names should be moved to the description and a "snappier" name invented where possible, and if that's hard maybe the  pref is ill conceived in the first please?
>>
>> I agree about the singular vs plural thing though, let's converge on plurals for features like Calendars and Blogs, and Categories (as if we have Category then why not Tag and Poll just after it?)
>>
>> However... Wiki vs Wikis? (only kidding, but there are always exceptions! ;)
>>
>> Must get on... as you know i'm not normally that bothered about the contents of strings, so i'm sure i'll get used to whatever is decided!
>>
>> jb
>>
>>
>>
>>> On 3 Apr 2017, at 06:43, Gary Cunningham-Lee <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> My opinion is that first-word-only capitalization makes the preference
>>> lists (as on admin pages, etc.) look too generic, visually reducing the
>>> significance of Tiki features. I think preference names that refer to
>>> (that are the name of) a feature should use title capitalization
>>> (https://en.wikipedia.org/wiki/Capitalization#Titles), as Tiki proper
>>> nouns, but other preferences should use sentence capitalization (first
>>> word and any contained proper nouns only are capitalized).
>>>
>>> An informal test for this is if the term can be used in a phrase like
>>> "the _____ feature", then it gets title-style capitalization; for
>>> example, "the user watches feature" seems appropriate, so "User Watches"
>>> is capitalized when referring to the feature.
>>>
>>> Context plays a part, unfortunately, as title-style capitalization is
>>> used when the term is used as a feature name, but the term isn't
>>> capitalized otherwise. In practice, I don't think it's hard at all to
>>> differentiate these cases (for example, in a string like "To post an
>>> article, Articles must be activated") but it's not cut and dried either.
>>>
>>> Long "almost-sentences" generally wouldn't get title-style
>>> capitalization because it isn't correct to say "the Minimum posts
>>> required before the thread configuration bar is displayed feature". A
>>> more rational argument is that this type of preference seems to be a
>>> detail or option within a larger preference rather than a standalone
>>> feature, so phrase length isn't really the condition for capitalization.
>>>
>>> Admittedly, there are subjective choices involved, to draw the line
>>> between "feature" and "sub- (or non-)feature preference", but I think
>>> most people would agree how to sort things. There are some edge-case
>>> preferences that aren't clearly a "feature" or an option or detail of
>>> one (like "CSS menus" on
>>> tiki-admin.php?page=general#contentadmin_general-3), so maybe we could
>>> just decide whether to be more formal or more casual generally, to sort
>>> these cases accordingly.
>>>
>>> Something related that's bothered me for a while is singular/plural
>>> inconsistencies. It seems like the logic to make "Forums", "Articles"
>>> and "Trackers" plural should also apply to Blogs, Calendars, Categories
>>> and File Galleries, etc. (that is, in these cases the general content
>>> area/type can have multiple distinct instances). This seems so
>>> self-evident that I imagine it's just neglect that has caused the
>>> situation to continue for so long. Or I guess mentally we just think
>>> "Category feature" when we read "Category" in the feature list, etc.
>>>
>>> I also can spend some time on making adjustments once we get a consensus.
>>>
>>> -- Gary
>>>
>>>
>>> On 4/3/2017 4:40 AM, lindon wrote:
>>>> Yes, title-case is the other direction we could go. But remember we have
>>>> pref names that are almost sentences, like the following:
>>>>
>>>> "Minimum posts required before the thread configuration bar is displayed"
>>>>
>>>> Probably most of the pref names are at least a short phrase, which will
>>>> generally read a little better with normal capitalization.
>>>>
>>>> Also the titles for the sections of the control panel pages (<legend>)
>>>> typically use normal capitalization (some of which I converted, but many
>>>> were that way already). To me we’d need to convert those too since they
>>>> are at a higher level than the pref labels.
>>>>
>>>> I did leave the tab titles with title-case, and also the plugin names,
>>>> since they seemed like titles, but could go either way on those.
>>>>
>>>> If, instead of considering pref names title-case, we instead say that
>>>> certain features are proper nouns, then it gets really complicated and
>>>> would result in a lot of work since that would mean we should be
>>>> capitalizing the feature name every time it is used. For example, on the
>>>> blogs control panel page the blog feature is referenced a number of
>>>> times in pref names ("Home blog", "Custom blog headings”, etc.) as well
>>>> as in descriptions. Arguably all of these are referring to the feature,
>>>> not to blogs generically, and so would need to be capitalized. We could
>>>> make a rule that only certain feature names should always be
>>>> capitalized, but that would be arbitrary and likely get messy again over
>>>> time as what is common versus unique changes.
>>>>
>>>> Just wanted to give an idea of what I was thinking when I made the
>>>> change. I still think normal capitalization is the best route, but of
>>>> course would accept the consensus.
>>>> Regards,
>>>> lindon
>>>>
>>>>>> On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]
>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>
>>>>>> Tee hee, thanks Lindon, sorry for the pressure ;)
>>>>>>
>>>>>> I'm as guilty as anyone about mixing things in commits but we should
>>>>>> strive to make each one as "atomic" as possible i think.
>>>>>>
>>>>>> Re the capitalisation inconsistency of things like Blogs or Articles
>>>>>> which as Tiki features but also "common" nouns i agree it would be
>>>>>> hard to tell, which is why i suggested "title-case" for all pref
>>>>>> names, but that is unfortunately exactly the opposite of what you did
>>>>>> in r62023 :P
>>>>>>
>>>>>> I guess we should discuss (on the dev list)?
>>>>>>
>>>>>> However, i'm really really going to do the branch now! :D
>>>>>>
>>>>>> jb
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 2 Apr 2017, at 14:52, lindon <[hidden email]
>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>> Wasn’t discussed and should have been, apologies for that. I’m happy
>>>>>>> to fix to whatever’s agreed to, so wouldn’t worry about the ultimate
>>>>>>> release.
>>>>>>>
>>>>>>> Preference names were mixed on capitalization, including for things
>>>>>>> that one could easily consider proper nouns, so opted to conform in
>>>>>>> the direction of lower case given they are mostly used as labels. In
>>>>>>> my experience going the other way becomes very subjective and leads
>>>>>>> to a proliferation of inconsistent capitalization. For example,
>>>>>>> think of blogs (or Blogs). This is as proper a noun as Tiki Connect
>>>>>>> and yet it is more often than not written in lower case in the
>>>>>>> preference labels (and elsewhere) unless it’s the first word in a
>>>>>>> label. There a lots of examples like this so it struck me as
>>>>>>> difficult to come up with a logic that wouldn’t wind being arbitrary
>>>>>>> and hard to maintain. Anyway, that’s the reason I went the direction
>>>>>>> I did.
>>>>>>>
>>>>>>> I understand the atomic commit point, but when doing basically REF
>>>>>>> cleanup on a series of files it doesn’t really make sense to me to
>>>>>>> try to anticipate how your changes should be parsed in case there is
>>>>>>> an objection. And going through the files multiple times to do each
>>>>>>> layer is really time-consuming. Having said that, I would have
>>>>>>> normally done a few files at a time except that I was sweating a
>>>>>>> 12-hour deadline :)
>>>>>>> Regards,
>>>>>>> lindon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]
>>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>>
>>>>>>>> Hi Lindon and devs
>>>>>>>>
>>>>>>>> Once again (same applies to r62021) there are several separate
>>>>>>>> things going on in this commit and combing them together makes it
>>>>>>>> hard to review what's going on... the part i'm not convinced about
>>>>>>>> is not using title case for titles, like "Tiki Connect" being
>>>>>>>> renamed to "Tiki connect" and "Daily Reports for User Watches" to
>>>>>>>> "Daily reports for user watches" where Tiki Connect, Daily Reports,
>>>>>>>> User Watches, File Galleries etc are all proper nouns as names for
>>>>>>>> features in Tiki and so i believe at least they should be capitalised.
>>>>>>>>
>>>>>>>> So the trouble is that if i roll this back the timeout warning
>>>>>>>> improvements (and added units) will also be lost... we need to
>>>>>>>> branch Tiki 17.x now and am short of time, as usual...
>>>>>>>>
>>>>>>>> Was this discussed and agreed somewhere and i missed it? My feeling
>>>>>>>> is that preference labels (that look like titles to me), should use
>>>>>>>> title case, i.e. everything except conjunctions and indefinite
>>>>>>>> articles should be capitalised, and should not use punctuation.
>>>>>>>>
>>>>>>>> I wonder what to do now... i guess i have to branch now and we tidy
>>>>>>>> it up in 17.x and trunk?
>>>>>>>>
>>>>>>>> jonny
>>>>>>>>
>>>>>>>>
>>>>>>>> P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)
>>>>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> TikiWiki-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ---
> Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta.
> https://www.avast.com/antivirus
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Brendan Ferguson
In reply to this post by Nagy Géza
+1 to Nagy

Brendan



On Apr 3, 2017, at 7:36 AM, Nagy Géza <[hidden email]> wrote:

my few cents about singular vs. plural: I prefer singular for feature
names (Wiki, Blog, Article, Category, etc), plural form is more about
referring to the recorded items (content list)

but I am fine with whatever the consensus is

cheers,

gezza


Nagy Géza

Ügyvezető/CEO
Oregional Kft./Ltd.
[hidden email]
oregional.hu

2017. 04. 03. 12:41 keltezéssel, Jonny Bradley írta:
Hi Gary++

I fear that this might be open to misinterpretation and a simpler rule would be preferable, like https://en.wikipedia.org/wiki/Capitalization#Titles or https://en.wikipedia.org/wiki/Letter_case#Title_case where we can point to a simple rule. Making it too Tiki-centric i think over complicates this...

Any 'Long "almost-sentences"' type names should be moved to the description and a "snappier" name invented where possible, and if that's hard maybe the  pref is ill conceived in the first please?

I agree about the singular vs plural thing though, let's converge on plurals for features like Calendars and Blogs, and Categories (as if we have Category then why not Tag and Poll just after it?)

However... Wiki vs Wikis? (only kidding, but there are always exceptions! ;)

Must get on... as you know i'm not normally that bothered about the contents of strings, so i'm sure i'll get used to whatever is decided!

jb



On 3 Apr 2017, at 06:43, Gary Cunningham-Lee <[hidden email]> wrote:

Hi,

My opinion is that first-word-only capitalization makes the preference
lists (as on admin pages, etc.) look too generic, visually reducing the
significance of Tiki features. I think preference names that refer to
(that are the name of) a feature should use title capitalization
(https://en.wikipedia.org/wiki/Capitalization#Titles), as Tiki proper
nouns, but other preferences should use sentence capitalization (first
word and any contained proper nouns only are capitalized).

An informal test for this is if the term can be used in a phrase like
"the _____ feature", then it gets title-style capitalization; for
example, "the user watches feature" seems appropriate, so "User Watches"
is capitalized when referring to the feature.

Context plays a part, unfortunately, as title-style capitalization is
used when the term is used as a feature name, but the term isn't
capitalized otherwise. In practice, I don't think it's hard at all to
differentiate these cases (for example, in a string like "To post an
article, Articles must be activated") but it's not cut and dried either.

Long "almost-sentences" generally wouldn't get title-style
capitalization because it isn't correct to say "the Minimum posts
required before the thread configuration bar is displayed feature". A
more rational argument is that this type of preference seems to be a
detail or option within a larger preference rather than a standalone
feature, so phrase length isn't really the condition for capitalization.

Admittedly, there are subjective choices involved, to draw the line
between "feature" and "sub- (or non-)feature preference", but I think
most people would agree how to sort things. There are some edge-case
preferences that aren't clearly a "feature" or an option or detail of
one (like "CSS menus" on
tiki-admin.php?page=general#contentadmin_general-3), so maybe we could
just decide whether to be more formal or more casual generally, to sort
these cases accordingly.

Something related that's bothered me for a while is singular/plural
inconsistencies. It seems like the logic to make "Forums", "Articles"
and "Trackers" plural should also apply to Blogs, Calendars, Categories
and File Galleries, etc. (that is, in these cases the general content
area/type can have multiple distinct instances). This seems so
self-evident that I imagine it's just neglect that has caused the
situation to continue for so long. Or I guess mentally we just think
"Category feature" when we read "Category" in the feature list, etc.

I also can spend some time on making adjustments once we get a consensus.

-- Gary


On 4/3/2017 4:40 AM, lindon wrote:
Yes, title-case is the other direction we could go. But remember we have
pref names that are almost sentences, like the following:

"Minimum posts required before the thread configuration bar is displayed"

Probably most of the pref names are at least a short phrase, which will
generally read a little better with normal capitalization.

Also the titles for the sections of the control panel pages (<legend>)
typically use normal capitalization (some of which I converted, but many
were that way already). To me we’d need to convert those too since they
are at a higher level than the pref labels.

I did leave the tab titles with title-case, and also the plugin names,
since they seemed like titles, but could go either way on those.

If, instead of considering pref names title-case, we instead say that
certain features are proper nouns, then it gets really complicated and
would result in a lot of work since that would mean we should be
capitalizing the feature name every time it is used. For example, on the
blogs control panel page the blog feature is referenced a number of
times in pref names ("Home blog", "Custom blog headings”, etc.) as well
as in descriptions. Arguably all of these are referring to the feature,
not to blogs generically, and so would need to be capitalized. We could
make a rule that only certain feature names should always be
capitalized, but that would be arbitrary and likely get messy again over
time as what is common versus unique changes.

Just wanted to give an idea of what I was thinking when I made the
change. I still think normal capitalization is the best route, but of
course would accept the consensus.
Regards,
lindon

On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]
<mailto:[hidden email]>> wrote:


Tee hee, thanks Lindon, sorry for the pressure ;)

I'm as guilty as anyone about mixing things in commits but we should
strive to make each one as "atomic" as possible i think.

Re the capitalisation inconsistency of things like Blogs or Articles
which as Tiki features but also "common" nouns i agree it would be
hard to tell, which is why i suggested "title-case" for all pref
names, but that is unfortunately exactly the opposite of what you did
in r62023 :P

I guess we should discuss (on the dev list)?

However, i'm really really going to do the branch now! :D

jb



On 2 Apr 2017, at 14:52, lindon <[hidden email]
<mailto:[hidden email]>> wrote:

Wasn’t discussed and should have been, apologies for that. I’m happy
to fix to whatever’s agreed to, so wouldn’t worry about the ultimate
release.

Preference names were mixed on capitalization, including for things
that one could easily consider proper nouns, so opted to conform in
the direction of lower case given they are mostly used as labels. In
my experience going the other way becomes very subjective and leads
to a proliferation of inconsistent capitalization. For example,
think of blogs (or Blogs). This is as proper a noun as Tiki Connect
and yet it is more often than not written in lower case in the
preference labels (and elsewhere) unless it’s the first word in a
label. There a lots of examples like this so it struck me as
difficult to come up with a logic that wouldn’t wind being arbitrary
and hard to maintain. Anyway, that’s the reason I went the direction
I did.

I understand the atomic commit point, but when doing basically REF
cleanup on a series of files it doesn’t really make sense to me to
try to anticipate how your changes should be parsed in case there is
an objection. And going through the files multiple times to do each
layer is really time-consuming. Having said that, I would have
normally done a few files at a time except that I was sweating a
12-hour deadline :)
Regards,
lindon



On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]
<mailto:[hidden email]>> wrote:

Hi Lindon and devs

Once again (same applies to r62021) there are several separate
things going on in this commit and combing them together makes it
hard to review what's going on... the part i'm not convinced about
is not using title case for titles, like "Tiki Connect" being
renamed to "Tiki connect" and "Daily Reports for User Watches" to
"Daily reports for user watches" where Tiki Connect, Daily Reports,
User Watches, File Galleries etc are all proper nouns as names for
features in Tiki and so i believe at least they should be capitalised.

So the trouble is that if i roll this back the timeout warning
improvements (and added units) will also be lost... we need to
branch Tiki 17.x now and am short of time, as usual...

Was this discussed and agreed somewhere and i missed it? My feeling
is that preference labels (that look like titles to me), should use
title case, i.e. everything except conjunctions and indefinite
articles should be capitalised, and should not use punctuation.

I wonder what to do now... i guess i have to branch now and we tidy
it up in 17.x and trunk?

jonny


P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


---
Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Gary Cunningham-Lee
In reply to this post by Nagy Géza
I can see using singular for back-end instances, but if we're talking
about where terms display in the UI, like the list of items under "Main
Features" on tiki-admin.php?page=features, then IMO plural is more
appropriate for the items that typically have plural instances, as this
seems more natural for users.

To make an analogy using something physical, a list of
features/preferences for a house would be something like

House features
------------------
Roof
Windows
Rooms
Heating system
Electrical system
Doors
Basement

It would be strange to list "window" or "room" because this is counter
to people's expectations about what a house has (in the developed world
context, though that may be evolving as the middle class declines ;-) ),
or what would appear in this kind of list (speaking about English here -
other languages may differ).

As you say, plural form is used for the recorded items, but IMO the
feature name just anticipates this typical situation, so I suggest using
plural here as well.

-- Gary


On 4/3/2017 8:36 PM, Nagy Géza wrote:

> my few cents about singular vs. plural: I prefer singular for feature
> names (Wiki, Blog, Article, Category, etc), plural form is more about
> referring to the recorded items (content list)
>
> but I am fine with whatever the consensus is
>
> cheers,
>
> gezza
>
>
> Nagy Géza
>
> Ügyvezető/CEO
> Oregional Kft./Ltd.
> [hidden email]
> oregional.hu
>
> 2017. 04. 03. 12:41 keltezéssel, Jonny Bradley írta:
>> Hi Gary++
>>
>> I fear that this might be open to misinterpretation and a simpler rule would be preferable, like https://en.wikipedia.org/wiki/Capitalization#Titles or https://en.wikipedia.org/wiki/Letter_case#Title_case where we can point to a simple rule. Making it too Tiki-centric i think over complicates this...
>>
>> Any 'Long "almost-sentences"' type names should be moved to the description and a "snappier" name invented where possible, and if that's hard maybe the  pref is ill conceived in the first please?
>>
>> I agree about the singular vs plural thing though, let's converge on plurals for features like Calendars and Blogs, and Categories (as if we have Category then why not Tag and Poll just after it?)
>>
>> However... Wiki vs Wikis? (only kidding, but there are always exceptions! ;)
>>
>> Must get on... as you know i'm not normally that bothered about the contents of strings, so i'm sure i'll get used to whatever is decided!
>>
>> jb
>>
>>
>>
>>> On 3 Apr 2017, at 06:43, Gary Cunningham-Lee <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> My opinion is that first-word-only capitalization makes the preference
>>> lists (as on admin pages, etc.) look too generic, visually reducing the
>>> significance of Tiki features. I think preference names that refer to
>>> (that are the name of) a feature should use title capitalization
>>> (https://en.wikipedia.org/wiki/Capitalization#Titles), as Tiki proper
>>> nouns, but other preferences should use sentence capitalization (first
>>> word and any contained proper nouns only are capitalized).
>>>
>>> An informal test for this is if the term can be used in a phrase like
>>> "the _____ feature", then it gets title-style capitalization; for
>>> example, "the user watches feature" seems appropriate, so "User Watches"
>>> is capitalized when referring to the feature.
>>>
>>> Context plays a part, unfortunately, as title-style capitalization is
>>> used when the term is used as a feature name, but the term isn't
>>> capitalized otherwise. In practice, I don't think it's hard at all to
>>> differentiate these cases (for example, in a string like "To post an
>>> article, Articles must be activated") but it's not cut and dried either.
>>>
>>> Long "almost-sentences" generally wouldn't get title-style
>>> capitalization because it isn't correct to say "the Minimum posts
>>> required before the thread configuration bar is displayed feature". A
>>> more rational argument is that this type of preference seems to be a
>>> detail or option within a larger preference rather than a standalone
>>> feature, so phrase length isn't really the condition for capitalization.
>>>
>>> Admittedly, there are subjective choices involved, to draw the line
>>> between "feature" and "sub- (or non-)feature preference", but I think
>>> most people would agree how to sort things. There are some edge-case
>>> preferences that aren't clearly a "feature" or an option or detail of
>>> one (like "CSS menus" on
>>> tiki-admin.php?page=general#contentadmin_general-3), so maybe we could
>>> just decide whether to be more formal or more casual generally, to sort
>>> these cases accordingly.
>>>
>>> Something related that's bothered me for a while is singular/plural
>>> inconsistencies. It seems like the logic to make "Forums", "Articles"
>>> and "Trackers" plural should also apply to Blogs, Calendars, Categories
>>> and File Galleries, etc. (that is, in these cases the general content
>>> area/type can have multiple distinct instances). This seems so
>>> self-evident that I imagine it's just neglect that has caused the
>>> situation to continue for so long. Or I guess mentally we just think
>>> "Category feature" when we read "Category" in the feature list, etc.
>>>
>>> I also can spend some time on making adjustments once we get a consensus.
>>>
>>> -- Gary
>>>
>>>
>>> On 4/3/2017 4:40 AM, lindon wrote:
>>>> Yes, title-case is the other direction we could go. But remember we have
>>>> pref names that are almost sentences, like the following:
>>>>
>>>> "Minimum posts required before the thread configuration bar is displayed"
>>>>
>>>> Probably most of the pref names are at least a short phrase, which will
>>>> generally read a little better with normal capitalization.
>>>>
>>>> Also the titles for the sections of the control panel pages (<legend>)
>>>> typically use normal capitalization (some of which I converted, but many
>>>> were that way already). To me we’d need to convert those too since they
>>>> are at a higher level than the pref labels.
>>>>
>>>> I did leave the tab titles with title-case, and also the plugin names,
>>>> since they seemed like titles, but could go either way on those.
>>>>
>>>> If, instead of considering pref names title-case, we instead say that
>>>> certain features are proper nouns, then it gets really complicated and
>>>> would result in a lot of work since that would mean we should be
>>>> capitalizing the feature name every time it is used. For example, on the
>>>> blogs control panel page the blog feature is referenced a number of
>>>> times in pref names ("Home blog", "Custom blog headings”, etc.) as well
>>>> as in descriptions. Arguably all of these are referring to the feature,
>>>> not to blogs generically, and so would need to be capitalized. We could
>>>> make a rule that only certain feature names should always be
>>>> capitalized, but that would be arbitrary and likely get messy again over
>>>> time as what is common versus unique changes.
>>>>
>>>> Just wanted to give an idea of what I was thinking when I made the
>>>> change. I still think normal capitalization is the best route, but of
>>>> course would accept the consensus.
>>>> Regards,
>>>> lindon
>>>>
>>>>>> On Apr 2, 2017, at 12:23 PM, Jonny Bradley <[hidden email]
>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>
>>>>>> Tee hee, thanks Lindon, sorry for the pressure ;)
>>>>>>
>>>>>> I'm as guilty as anyone about mixing things in commits but we should
>>>>>> strive to make each one as "atomic" as possible i think.
>>>>>>
>>>>>> Re the capitalisation inconsistency of things like Blogs or Articles
>>>>>> which as Tiki features but also "common" nouns i agree it would be
>>>>>> hard to tell, which is why i suggested "title-case" for all pref
>>>>>> names, but that is unfortunately exactly the opposite of what you did
>>>>>> in r62023 :P
>>>>>>
>>>>>> I guess we should discuss (on the dev list)?
>>>>>>
>>>>>> However, i'm really really going to do the branch now! :D
>>>>>>
>>>>>> jb
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 2 Apr 2017, at 14:52, lindon <[hidden email]
>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>> Wasn’t discussed and should have been, apologies for that. I’m happy
>>>>>>> to fix to whatever’s agreed to, so wouldn’t worry about the ultimate
>>>>>>> release.
>>>>>>>
>>>>>>> Preference names were mixed on capitalization, including for things
>>>>>>> that one could easily consider proper nouns, so opted to conform in
>>>>>>> the direction of lower case given they are mostly used as labels. In
>>>>>>> my experience going the other way becomes very subjective and leads
>>>>>>> to a proliferation of inconsistent capitalization. For example,
>>>>>>> think of blogs (or Blogs). This is as proper a noun as Tiki Connect
>>>>>>> and yet it is more often than not written in lower case in the
>>>>>>> preference labels (and elsewhere) unless it’s the first word in a
>>>>>>> label. There a lots of examples like this so it struck me as
>>>>>>> difficult to come up with a logic that wouldn’t wind being arbitrary
>>>>>>> and hard to maintain. Anyway, that’s the reason I went the direction
>>>>>>> I did.
>>>>>>>
>>>>>>> I understand the atomic commit point, but when doing basically REF
>>>>>>> cleanup on a series of files it doesn’t really make sense to me to
>>>>>>> try to anticipate how your changes should be parsed in case there is
>>>>>>> an objection. And going through the files multiple times to do each
>>>>>>> layer is really time-consuming. Having said that, I would have
>>>>>>> normally done a few files at a time except that I was sweating a
>>>>>>> 12-hour deadline :)
>>>>>>> Regards,
>>>>>>> lindon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Apr 2, 2017, at 9:25 AM, Jonny Bradley <[hidden email]
>>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>>
>>>>>>>> Hi Lindon and devs
>>>>>>>>
>>>>>>>> Once again (same applies to r62021) there are several separate
>>>>>>>> things going on in this commit and combing them together makes it
>>>>>>>> hard to review what's going on... the part i'm not convinced about
>>>>>>>> is not using title case for titles, like "Tiki Connect" being
>>>>>>>> renamed to "Tiki connect" and "Daily Reports for User Watches" to
>>>>>>>> "Daily reports for user watches" where Tiki Connect, Daily Reports,
>>>>>>>> User Watches, File Galleries etc are all proper nouns as names for
>>>>>>>> features in Tiki and so i believe at least they should be capitalised.
>>>>>>>>
>>>>>>>> So the trouble is that if i roll this back the timeout warning
>>>>>>>> improvements (and added units) will also be lost... we need to
>>>>>>>> branch Tiki 17.x now and am short of time, as usual...
>>>>>>>>
>>>>>>>> Was this discussed and agreed somewhere and i missed it? My feeling
>>>>>>>> is that preference labels (that look like titles to me), should use
>>>>>>>> title case, i.e. everything except conjunctions and indefinite
>>>>>>>> articles should be capitalised, and should not use punctuation.
>>>>>>>>
>>>>>>>> I wonder what to do now... i guess i have to branch now and we tidy
>>>>>>>> it up in 17.x and trunk?
>>>>>>>>
>>>>>>>> jonny
>>>>>>>>
>>>>>>>>
>>>>>>>> P.S. See https://en.wikipedia.org/wiki/Atomic_commit for more :)
>>>>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> TikiWiki-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ---
> Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta.
> https://www.avast.com/antivirus
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Torsten Fabricius-4
Adding to that, that in Tiki it is indeed possible to create an
arbitrary number of different forums, blogs, newsletters etc.

Thus the plural makes sense for that aswell.

As a house has one roof but several  rooms, doors and windows, Tiki has
one wiki, but several forums, blogs and newsletters.

Thx Gary, as a carpenter I did understand this picture.

Regards

-- T

On 04.04.2017 06:02, Gary Cunningham-Lee wrote:

> I can see using singular for back-end instances, but if we're talking
> about where terms display in the UI, like the list of items under "Main
> Features" on tiki-admin.php?page=features, then IMO plural is more
> appropriate for the items that typically have plural instances, as this
> seems more natural for users.
>
> To make an analogy using something physical, a list of
> features/preferences for a house would be something like
>
> House features
> ------------------
> Roof
> Windows
> Rooms
> Heating system
> Electrical system
> Doors
> Basement
>
> It would be strange to list "window" or "room" because this is counter
> to people's expectations about what a house has (in the developed world
> context, though that may be evolving as the middle class declines ;-) ),
> or what would appear in this kind of list (speaking about English here -
> other languages may differ).
>
> As you say, plural form is used for the recorded items, but IMO the
> feature name just anticipates this typical situation, so I suggest using
> plural here as well.
>
> -- Gary
>
>



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Cloutier, Philippe (RESSOURCE EXTERNE)
In reply to this post by Jonny Bradley-4
> -----Message d'origine-----
> De : Jonny Bradley [mailto:[hidden email]]
> Envoyé : 3 avril 2017 06:41
> À : Tiki developers <[hidden email]>
> Objet : Re: [Tiki-devel] Pref name capitalization
>
> Hi Gary++
>
> I fear that this might be open to misinterpretation and a simpler rule would be preferable, like
> https://en.wikipedia.org/wiki/Capitalization#Titles or
> https://en.wikipedia.org/wiki/Letter_case#Title_case where we can point to a simple rule. Making it
> too Tiki-centric i think over complicates this...

I am not following closely and not sure what this is compared with, but I would not qualify the rules for title case as simple, and hope that no preference names use title case (unless that happens to match normal case). Particularly complicated in the context of an international project.

[...]
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

lindon-4
Okay, taking stock on capitalization for preference names, seems like there’s general agreement Tiki Connect should be capitalized as a proper noun. Beyond that by my count (and apologies if I’ve miscounted) here’s how things stand for those who have expressed a view on capitalization of preference names (not addressing the plural issue that got added to the discussion but which I didn’t change):

Sentence capitalization (aka first-word-only)
Three votes here (one being mine). One vote also stipulated that anything H1 - H6 should use title case (this is more for the <legend> titles on the control panel forms).

Capitalize major features
Two votes here (and a volunteer!).

Title Case
One vote here I think. Someone mentioned that title case presents an issue for translation - is that view shared by others? If so, that would mean we have an issue in all the other places where we use title case (like tab labels, button text, etc.) so not sure we need to consider this, but I’m not a translation expert.


Would be better to get some more views if possible as I’m not sure we can say there’s a consensus yet on the preferred style. 

The difficulty of course is that these names are a mixture of things. On the one hand they are labels. However, in many cases they are also brief statements to which the checkbox gives a yes or no answer (e.g., “Visible to admin only”, “Use group homepages”), and many of these probably wouldn't change even if we make an effort to shorten names. In many cases they are feature names, but even in such cases there is an implied statement, so that “File Gallery” really means “Enable file gallery” on these forms, which is checked yes or no.

Additionally, if considered titles, there’s the question of what style do we want for these titles, which is also a style choice with potentially different choices for different situations. Using title case is a more formal/traditional look, and that choice has already been made for certain things like admin page names and navigation links/buttons, tabs, buttons, etc. Sentence capitalization for headers/titles is a more casual look and is often used for various header levels in Tiki, but not consistently.

Would be good to get more votes and appreciate any further opinions.
Regards,
lindon



On Apr 4, 2017, at 4:31 PM, Cloutier, Philippe (RESSOURCE EXTERNE) <[hidden email]> wrote:

-----Message d'origine-----
De : Jonny Bradley [[hidden email]]
Envoyé : 3 avril 2017 06:41
À : Tiki developers <[hidden email]>
Objet : Re: [Tiki-devel] Pref name capitalization

Hi Gary++

I fear that this might be open to misinterpretation and a simpler rule would be preferable, like
https://en.wikipedia.org/wiki/Capitalization#Titles or
https://en.wikipedia.org/wiki/Letter_case#Title_case where we can point to a simple rule. Making it
too Tiki-centric i think over complicates this...

I am not following closely and not sure what this is compared with, but I would not qualify the rules for title case as simple, and hope that no preference names use title case (unless that happens to match normal case). Particularly complicated in the context of an international project.

[...]
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Pref name capitalization

Cloutier, Philippe (RESSOURCE EXTERNE)

Hi Lindon,

The 2 only translation issues I can see with title case would be:

1.      If a translator is not doing in-context translation, he could wonder whether the string contains proper nouns.

2.      It can unnecessarily increase the number of strings to be translated.

 

In other words, I don’t think this limits how good a translation can be. It could just make it a little more expensive to develop that translation.

 

De : lindon [mailto:[hidden email]]
Envoy
é : 8 avril 2017 11:52
À : Tiki developers <[hidden email]>
Objet : Re: [Tiki-devel] Pref name capitalization

 

Okay, taking stock on capitalization for preference names, seems like there’s general agreement Tiki Connect should be capitalized as a proper noun. Beyond that by my count (and apologies if I’ve miscounted) here’s how things stand for those who have expressed a view on capitalization of preference names (not addressing the plural issue that got added to the discussion but which I didn’t change):

 

Sentence capitalization (aka first-word-only)

Three votes here (one being mine). One vote also stipulated that anything H1 - H6 should use title case (this is more for the <legend> titles on the control panel forms).

 

Capitalize major features

Two votes here (and a volunteer!).

 

Title Case

One vote here I think. Someone mentioned that title case presents an issue for translation - is that view shared by others? If so, that would mean we have an issue in all the other places where we use title case (like tab labels, button text, etc.) so not sure we need to consider this, but I’m not a translation expert.

 

 

Would be better to get some more views if possible as I’m not sure we can say there’s a consensus yet on the preferred style. 

 

The difficulty of course is that these names are a mixture of things. On the one hand they are labels. However, in many cases they are also brief statements to which the checkbox gives a yes or no answer (e.g., “Visible to admin only”, “Use group homepages”), and many of these probably wouldn't change even if we make an effort to shorten names. In many cases they are feature names, but even in such cases there is an implied statement, so that “File Gallery” really means “Enable file gallery” on these forms, which is checked yes or no.

 

Additionally, if considered titles, there’s the question of what style do we want for these titles, which is also a style choice with potentially different choices for different situations. Using title case is a more formal/traditional look, and that choice has already been made for certain things like admin page names and navigation links/buttons, tabs, buttons, etc. Sentence capitalization for headers/titles is a more casual look and is often used for various header levels in Tiki, but not consistently.

 

Would be good to get more votes and appreciate any further opinions.

Regards,

lindon

 

 

 

On Apr 4, 2017, at 4:31 PM, Cloutier, Philippe (RESSOURCE EXTERNE) <[hidden email]> wrote:

 

-----Message d'origine-----
De : Jonny Bradley [[hidden email]]
Envoyé : 3 avril 2017 06:41
À : Tiki developers <[hidden email]>
Objet : Re: [Tiki-devel] Pref name capitalization

Hi Gary++

I fear that this might be open to misinterpretation and a simpler rule would be preferable, like
https://en.wikipedia.org/wiki/Capitalization#Titles or
https://en.wikipedia.org/wiki/Letter_case#Title_case where we can point to a simple rule. Making it
too Tiki-centric i think over complicates this...


I am not following closely and not sure what this is compared with, but I would not qualify the rules for title case as simple, and hope that no preference names use title case (unless that happens to match normal case). Particularly complicated in the context of an international project.

[...]
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Loading...