Look at hathor/html/layouts/toolbar/

@infograf768 tnx!

My mistake
In fact, we just need to add a css in the specifc Hathor files

.icon-32-unfeatured {
    background-image: url(../images/toolbar/icon-32-unfeatured.png);
}

The issue is we do NOT have an icon-32-unfeatured.png icon for Hathor

We already have the ability to "unfeature"

If you go to "Article Manager: Featured Articles" you will see a button in the toolbar "remove" - this will remove the featured status on any article

Yes, Brian, but not in the Articles Manager: Articles

Do we really need it? I dont think so. Sergio was creating this because he
didnt think there was any way at all to do this except through the db

On 22 December 2014 at 09:33, infograf768 notifications@github.com wrote:

Yes, Brian, but not in the Articles Manager

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

That could be. BTW: "Remove" is not really user friendly. (Remove what? is the first question anyone would ask)

Thats a different issue (and I agree it could be named better but its been
called that for a very very long time)

On 22 December 2014 at 09:39, infograf768 notifications@github.com wrote:

That could be. BTW: "Remove" is not really user friendly. (Remove what? is
the first question anyone would ask)

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@infograf768 hathor/images/toolbar/icon-32-featured.png has also the "inactive" version inside (like all other toolbars icons), so maybe it is just a matter of setting the background in CSS with the correct offset...

IMHO, for orthogonality, as we have publish/unpublish we can also have featured/unfeatured. It wouldn't do any harm, I guess...

Well personally speaking you are solving a problem that doesn't exist. I
would prefer we were removing buttons from the toolbars not adding new ones

I can remove the featured status of an article in the featured articles
manager. And unfeatured is a nonsense word that doesnt exist in english

My 2c

On 22 December 2014 at 09:44, Sergio Manzi notifications@github.com wrote:

IMHO, for orthogonality, as we have publish/unpublish we can also have
featured/unfeatured. It wouldn't do any harm, I guess...

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

And unfeatured is a nonsense word that doesnt exist in english

Agreed, but I'm sure you can find a better wording.

Not really - its one of those words that doesnt have an obvious antonym

On 22 December 2014 at 10:08, Sergio Manzi notifications@github.com wrote:

And unfeatured is a nonsense word that doesnt exist in english

Agreed, but I'm sure you can find a better wording.

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman honestly I don't have a solution for this, but the JUNFEATURED string is already defined as "Unfeatured"

@infograf768 fixed Hathor icons. Are there more to be fixed? The icon-16 and icon-48 versions, maybe?

I still think this is an unneeded change

On 22 December 2014 at 10:27, Sergio Manzi notifications@github.com wrote:

@brianteeman https://github.com/brianteeman honestly I don't have a
solution for this, but the JUNFEATURED string is already defined as
"Unfeatured"

@infograf768 https://github.com/infograf768 fixed Hathor icons. Are
there more to be fixed? The icon-16 and icon-48 versions, maybe?

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@smz "Unfeatured" is an adjective (opposite of featured) or a past particple of the verb "to feature". Bot normally buttons should describe an action, e.g. "Remove from featured" or "Remove featured property" or maybe also" Unfeature" (without "ed" at the end). With respect to limited text length in a button, I would suggest "Unfeature" ... or why not "Featured" with strike-through (would make clear the button removes a property)? So or so: If the existing text JUNFEATURED is used to describe a property, then we would need another JText for the button action. Honestly, I am not a native speaker ... but my experience says that natice speakers not always are good in spelling or grammar of their own language ;-)

You are correct it should be Feature/Unfeature

On 22 December 2014 at 10:42, Richard Fath notifications@github.com wrote:

@smz https://github.com/smz "Unfeatured" is an adjective (opposite of
featured) or a past particple of the verb "to feature". Bot normally
buttons should describe an action, e.g. "Remove from featured" or "Remove
featured property" or maybe also" Unfeature" (without "ed" at the end).
With respect to limited text length in a button, I would suggest
"Unfeature" ... or why not "Featured" with strike-through (would make clear
the button removes a property)? So or so: If the existing text JUNFEATURED
is used to describe a property, then we would need another JText for the
button action. Honestly, I am not a native speaker ... but my experience
says that natice speakers not always are good in spelling or grammar of

their own language ;-)

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5485
http://issues.joomla.org/tracker/joomla-cms/5485.< /sub>

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Well, I agree with @smz at this point that if in the article magaer view there is a way so set it to featured, people would expect there to be a way for unset, too.

On the other hand, @brianteeman is right, too: There is already a way to do it, also with batch processing, so why make another one? A reason to dot this is maybe that the current solution is not very consistent.

But if we have a clean solution in the article manager: Is then the "featured articles" view in the content component not obsolete? It is currently only needed for this "unfeaturing" of articles and having a quick view without having to set a filter in the article manager. But if we have both in the article manager, then the featured article view is not needed anymore, from my point of view. And this would be the clean solution with respect to make the CMS more tiny and lean, I think.

From my point of view, a clean and complete implementation of @smz 's idea could look as follows:
1. The text for the existing button in the article manager would be changed from "Feaured" to "Feature", but the symbol would be the same as now (span with class="icon-featured").
2. A new button right beside would have text "Unfeature", and the symbol for this button would be the same as the one already used for the corresponging push-buttons used for each article (i.e. span with class="icon-unfeatured").
3. The search tools would be extended by a filter option for the featured property of the articles.
4. The "Featured articles" menu item and the corresponding admin view of the content component would be obsolete then and so could be removed.
I am curious on opinions, and if necessary I can try to help with implementation.

I certainly would not kill the menu item as well as the Featured Manager in the 3.x series...

@infograf768 Then maybe in 4.0?

And P.S. to my idea before: If the search tools would be extended by an option to show featured articles only, it also should have an option to show unfeatured articles only.

Hmm, another idea without an additional button would be to have the existing button named something like "Toggle featured" and let it result in changing the featured status of the selected articles to the opposite of what the particular article currently has ... but this would need changes in the SQL statement for update (because some of the selected articles could be featured and others not), and with the long button text it need almost as much space as 2 buttons, except when we just name the button "Change" or "Toggle" and have the info that it is related to the "Featured" property only in the star symbol and maybe in a tool tip text.

As far as regards strings if there is a consensus I can take care of that within this PR and introduce two new strings JFEATURE and JUNFEATURE

@richard67 idea to introduce a filter by "featured/unfeatured" in the search tools is a very good one and will nicely complement this PR and the logic behind it.

The "toggle" button will be much more difficult to implement as it will have to consider the case where multiple items with different "featured" status are selected, and again it will not be consistent with what we do for "Publish/Unpublish"

@smz Yes, you are right: For "Publish/Unpublish" a single toggle button would be nice, too ;-)

Regarding SQL update statement for toggle buttons: If I would have to deal here with Oracle SQL only, I would know what I have to do to have one single statement for toggle (UPDATE sometable SET blablacolumn = DECODE(blablacolumn,1,0,1) ...) ;-)

I really think you are solving a problem that doesnt exist.

On 22 December 2014 at 11:44, Richard Fath notifications@github.com wrote:

@smz https://github.com/smz Yes, you are right: For "Publish/Unpublish"
a single toggle button would be nice, too ;-)

Regarding SQL update statement for toggle buttons: If I would have to deal
here with Oracle SQL only, I would know what I have to do to have one
single statement for toggle (UPDATE sometable SET blablacolumn =

DECODE(blablacolumn,1,0,1) ...) ;-)

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5485
http://issues.joomla.org/tracker/joomla-cms/5485.

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman Well, I just wanted to share a few ideas on how it could be done if something would be done. No need to do all that now.
@smz Sorry, I did not want to mess up your issue with too much other stuff and so maybe helped to make Brian a bit nervous we could want to mess up all with the upcoming 3.4 ;-)

I think actually a button to change the status to "not Featured" in the Article Manager is needed. And despite having a button in Featured Articles manager for this operation, I think the name "Remove" is not the most suitable for this. IMHO

I am definitely with renamimg "remove" to "unfeature"

I just personally feel anything more is unnecessary

I am definitely with renamimg "remove" to "unfeature"

Then we should also change the button name in Article Manager from "Featured" to "Feature". The problem here is that (forgetting any i18n issue) "feature" in English is both a name and a verb and some incomprehension may arise also because, as a verb, it doesn't have the meaning of "set the featured attribute". Also, according to dictionary.com and the OED, there isn't an "unfeature" English verb. Personally I think that "Featured" and "Unfeatured" with the implied action verb "set attribute to" is clear enough and it has been so far.

I just personally feel anything more is unnecessary

Clear enough. Personally I instead think that the anomaly here is the "Featured Articles" view. Why then not to have a "Published Articles" and an "Archived Articles" view too? If all can be done in a single view it will be easier and more straightforward (especially if augmented by @richard67 proposal to have Featured/Unfeatured as search options).

@infograf768 I tested this with all Hathor color variations and I see no problem, therefore I think this is ready for testing.

We do have in fact issues for translating "Unfeatured" in French and I guess in other languages too.
In French, we use for Featured
JFEATURED="En vedette"
and for Unfeatured
JUNFEATURED="Non en vedette"

For those who understand French, this is very bad wording.

[For the star in the column we use:
COM_CONTENT_TOGGLE_TO_UNFEATURE="Cliquez pour supprimer le statut 'En vedette' de l'article"]

We also have translations for JFEATURE and JUNFEATURE:
In English:
JFEATURE="Feature"
JUNFEATURE="Unfeature"
in French
JFEATURE="Mettre en vedette"
JUNFEATURE="Ne pas mettre en vedette"

The problem (as shown by the french) is that in Joomla en-GB we regularly
try to make nouns out of verbs.

Something that I hope to resolve with the en-GB standards currently being
created

On 23 December 2014 at 09:56, infograf768 notifications@github.com wrote:

We do have in fact issues for translating "Unfeatured" in French and I
guess in other languages too.
In French, we use for Featured
JFEATURED="En vedette"
and for Unfeatured
JUNFEATURED="Non en vedette"

For those who understand French, this is very bad wording.

[For the star in the column we use:
COM_CONTENT_TOGGLE_TO_UNFEATURE="Cliquez pour supprimer le statut 'En
vedette' de l'article"]

We also have translations for JFEATURE and JUNFEATURE:
In English:
JFEATURE="Feature"
JUNFEATURE="Unfeature"
in French
JFEATURE="Mettre en vedette"
JUNFEATURE="Ne pas mettre en vedette"

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@test Tested with success for both Hathor and Isis template.

Regarding usage of actions (verbs) instead of adjectives for the button texts, I a gree with @smz that it is ok for the "Featured" and "Unfeatured" buttons to keep using the adjectives - it really is obvious that the button is for changing the attribute of the article.

Changes on language strings we should do in a separate PR - with some input of @infograf768 on what he thinks what has to be done I could make this PR.

To be honest, sorry @smz , I meanwhile have a certain understanding for @brianteeman 's opinion that this PR here is not really needed.

Anyway, I thought I should at least help with test, even if my opinion on it is now indifferent - not pro, not contra.

But if this PR here will be accepted and merged, It would be logical and consistent to have a filter option for "Featured"/"Not featured" in the article list, too. I am not sure if I could do a PR for this, but I can try to find out. But if this PR here is not merged for some reason, then the filter also would not be neccessary.

@richard67 I agree with you an all points, and respect your opinions. And thanks for testing!

I've already started looking into the searchtools bar and I'm already lost into a maze of views, layouts and xml option files: I'm really unsure if I'll be able to get out of here...

The two things together will really make sense. Another (unrelated) aspect I would like to tackle is the possibility to add "Category" as a sortable column to the articles list. For my workflow that would be really handy, surly more than other already sortable columns.

Thanks again,

Sergio

@smz Well, regarding the maze of this and that for the search tools bar: In addition to that, it seems that everything has to be done twice, once for the Joomla! standard functionality and then for the Hathor template with its overrides for almost everything.
I am not sure if these overrides always have been updated with latest changes made for the standards, and so it could be worth to make a separate PR for cleaning up Hathor's overrides.
But after having tested this PR here and so having seen Hathor's ugly look again after a long time, I am in favour of throwing away the Hathor template completely (even if many Joomlers may want to kill me for this) ;-)

I have the same feelings toward Hathor, but I'm afraid it is still needed for accessability...

(Sorry, answering from my phone)

Regarding changing the "Remove" button in the featured articles list, I think it should not be done by just changing the language string, because there is a string with name JTOOLBAR_REMOVE used, which seems to exist only for this one button:

C:\xampp\htdocs\joomla3>findstr /s /c:"JTOOLBAR_REMOVE" *.*
administrator\components\com_content\views\featured\view.html.php:
JToolbarHelper::custom('featured.delete', 'remove.png', 'remove_f2.png', 'JTOOLBAR_REMOVE', true);
administrator\language\de-DE\de-DE.ini:JTOOLBAR_REMOVE="Entfernen"
administrator\language\en-GB\en-GB.ini:JTOOLBAR_REMOVE="Remove"
administrator\language\ru-RU\ru-RU.ini:JTOOLBAR_REMOVE="ðúð¦ð¦ð+ð©ÐéÐî"
C:\xampp\htdocs\joomla3>

So of course the JTOOLBAR_REMOVE text simply could be changed to "Unfeature" or "Unfeatured", but then the string name would be confusing, so this is a kind of hack, and the clean solution would be to change the view.html.php so it uses the JUNFEATURED text, as the new button in the article list implemented with this PR here does.
But then the JTOOLBAR_REMOVE text has to be marked as depreceated somhow in the language file(s), because not used anymore after such a clean change.
@languagespecialists (e.g. @infograf768 ): Which solution would you pefer in a separate, new PR? Hack or clean solution?

P.S.: Or we make a new text JTOOLBAR_UNFEATURED or so, in order to have it at the right place?

The simplest (in the Featured view) is to use
JToolbarHelper::custom('featured.delete', 'remove.png', 'remove_f2.png', 'JUNFEATURE', true);

We get for French

@infograf768 Ok, I will prepare a PR for changing the feaured articles view to use the JUNFEATURE text. But how is it with the existing text JTOOLBAR_REMOVE? It will not be used anymore after the change. Shall it then be removed from the language file? Or somehow (in a comment) marked as depreceated after 3.4.0?

@infograf768 And shouldn't we make the button in the featured articles list be consistent with the one added by @smz 's PR here?
This would be then
JToolbarHelper::custom('featured.delete', 'unfeatured.png', 'featured_f2.png', 'JUNFEATURED', true);
and would looks as follows:



This would result in shorter buttons as if we would use "JUNFEATURE".
@all Please let me know your opinion. When I later have posted the link to the number of the new PR soon, you may comment there then.

The string for the button in en-GB must be Unfeature and not Unfeatured
Just as it is Publish and not Published

On 24 December 2014 at 12:25, Richard Fath notifications@github.com wrote:

@infograf768 https://github.com/infograf768 And shouldn't we make the
button in the featured articles list be consistent with the one added by
@smz https://github.com/smz 's PR here?
This would be then
JToolbarHelper::custom('featured.delete', 'unfeatured.png', '
featured_f2.png', 'JUNFEATURED', true);
and would looks as follows;
[image: featured_en-gb]
https://cloud.githubusercontent.com/assets/7413183/5548379/ec3de0be-8b6f-11e4-9b66-76862c6ca68a.png
[image: featured_fr-fr]
https://cloud.githubusercontent.com/assets/7413183/5548381/f3107e6a-8b6f-11e4-8807-c6e6dd7c6033.png
[image: featured_de-de]
https://cloud.githubusercontent.com/assets/7413183/5548382/f56b050e-8b6f-11e4-83ac-3d2fefbe0227.png
This would result in shorter buttons.
@all https://github.com/all Please let me know your opinion. When I
later have posted the link to the number of the new PR soon, you may
comment there then.

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@infograf768 and @richard67: Sorry guys, I'm confused here (also because I'm now following another issue). I see you are handling the "Featured Articles" view, but what is not clear to me is if I should modify something in this PR to be "aligned" with you or if it is OK as it is...

Also (but this is TOTALLY OT), I just aligned my test site with current staging and now saving whatever "item" (Articles, Categories, Menu items, Modules, ... whatever) I'm getting an error message which is of class alert alert-error in most cases, but just alert in Menu Manger. "Items" are anyway saved, so it seems an issue with the error messages. In Category Manager after the apparently botched save, the category title is also cleared It is a regression in current staging: thanks to all who rushed helping me... Issue opened.

@brianteeman Now I am confused, because a few comments above you mentioned that "unfeature" does not exist in English language.
And so for this PR here @smz suggested to use the adjectives (Unfeatured/Featured) for the buttons.
As he pointed out, and I agree with him, it is clear what the buttons do even if they are labelled with adjectives (properties) and not verbs (actions).
And we should not use the JFEATURE/JUNFEATURE texts for the buttons in my opinion, because these are very long texts we currently use only for tool tips.
But if we agree to change the buttons from adjectives to verbs, then we should change the texts JFEATURED/JUNFEATURED in the language files, and so on this PR here and my new one nothing will change. And this then can be done in a separate PR independently from this here and my new one.

@brianteeman ... and it should be done in a separate PR because the changes have to be mentioned by all translations then (@infograf768 please check if this would be a bad idea).

Back on topic (but I'll be extremely grateful if you can check the aforementioned issues I'm having), if we really need a verb and do not want to adventure in dangerous neologisms territory, what about "Flag as featured" / "Un-flag as featured"?

I agree with the use of feature (the action to make an article featured) and unfeature (the action of removing the featured status of an article). If one uses the noun, we would need a third state - an article that is not featured, never has been featured and doesn't need anything changing! Therefore, it is definitely an action not a noun that describes the state.

Unfeature, traditionally, is not en-GB but we realise that we have a living language and the whole idea of language is communication. Does everyone understand what unfeature means? I do. Unfeature is beginning to creep in to dictionaries - I think dictionary.com recognises it.

@smz The verb "to flag" is not easy to translate to other languages, same as "to feature". Or how would you translate it into Italian?

To all who wanted the "Remove" button in the featured articles view to be changed to something less misleading:
I have created a PR for this: #5511
Please check and if necessary comment and of course test if poossible.
Thanks in advance.

Please make the string change in this PR. There really is no need to make
another PR just for a single character

On 24 December 2014 at 13:21, Richard Fath notifications@github.com wrote:

@smz https://github.com/smz The verb "to flag" is not easy to translate
to other languages, same as "to feature". Or how would you translate it

into Italian?

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5485
http://issues.joomla.org/tracker/joomla-cms/5485.

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

To flag, to feature in Italian (and other languages). Isn't that the idea of translation to different languages? Localisation? Making your translation understandable in your language to your language speakers? All the current en-GB initative is doing is making sure that the source words are correct. The translations are entirely up to the en-GB/other lang translators thereby making the strings understandable to their native other lang speakers. Do you agree?

+100

On 24 December 2014 at 13:25, Hils notifications@github.com wrote:

To flag, to feature in Italian (and other languages). Isn't that the idea
of translation to different languages? Localisation? Making your
translation understandable in your language to your language speakers? All
the current en-GB initative is doing is making sure that the source words
are correct. The translations are entirely up to the en-GB/other lang
translators thereby making the strings understandable to their native other
lang speakers. Do you agree?

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@Hils

... I think dictionary.com recognises it.

Nope!

I agree on the "living language" concept, but... carefully.

@richard67 "To flag" is not that difficult to translate IMHO...

@brianteeman and all other, will gladly make any required modification to this PR when a consensus will be reached.

Sorry but we are not going to have non en-GB native speakers making
decisions on en-GB strings. Thats why en-GB is a mess of inconsistencies
right now.

On 24 December 2014 at 13:27, Sergio Manzi notifications@github.com wrote:

@Hils https://github.com/Hils

... I think dictionary.com recognises it.

Nope! [image: ]

I agree on the "living language" concept, but... carefully.

@richard67 https://github.com/richard67 "To flag" is not that difficult
to translate IMHO...

@brianteeman https://github.com/brianteeman and all other, will gladly
make any required modification to this PR when a consensus will be reached.

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Sorry but we are not going to have non en-GB native speakers making decisions on en-GB strings. Thats why en-GB is a mess of inconsistencies right now.

Is this addressed to me? And in case, on the basis of which affirmation?

http://dictionary.reference.com/browse/unfeatured - check out the Related forms section - unfeatured is an accepted adjective - which is a start!

@hils I was referring to the verb, "to unfeature"...

living language @smz - things change and are changing to make communication better. Our Oxford Dictionary (our Gold Standard) adds new words frequently.

@smz Regarding alignment between your PR are here and my PR #5511 : Mine depends on yours with the CSS for Hathor and the decision which button icon and text to use. I made mine using same as your new button.

So if you change the JUNFEATURED text in language files your PR, mine will be ok too because using the same JUNFEATURED.

Only if you decide to use the JUNFEATURE text (what I do not recommend) then I would have to change my PR, too, to be consistent.

If you decide to change texts in language files with your PR: Please note that you have to change 2 language strings and not only one as Brian mentioned.

The JFEATURED and the JUNFEATURED have to be consistent with each other, same as the JFEATURE and the JUNFEATURE.

@brianteeman I am not English native speaker, but I have read in my life such bad texts from native speakers in their own language, full of grammar and spelling errors, and I do not mean quick typing in emails or SMS! And so I do not really think to be a native speaker is always an advantage regarding correctness.

@hils I 100% agree, totally and warmheartedly. What I was trying to say (and this IMHO is valid not only for English but every language) is that introducing a neologism should not be a lazy shortcut to finding a proper wording. Unhapply currently spoken Italian abounds of absurd neologisms of the latter kind...

Last point. As writers of the core en-GB strings, we should be aware of the UX as well. I know you all understand that. So if there is a word that is 'neat' enough to fit the space on a button plus be understandable in en-GB, I have no objection to it. If I was writing non-technically (a novel for example) I would disagree with myself :D

@Hils Well, in my real life job i am also expert on UX, this is why I meanwhile like it as it is, with "Featured"/"Unfeatured", i.e. adjectives, because all is clear and understandable, and the buttons are tiny in every translation as far as I can see (see also my screenshots above), compared to using the "JUNFEATURED" text, which is very long in most translations.

@richard67 OK! I'm pulling myself away of this linguistic diatribe. When a decision will be taken I will comply.

I would not, anyway, like that the concept passes that introducing new code requiring new strings is something reserved to sons and daughters of Albion: everyone with his/her broken English should be allowed to. Then English linguistics/translators can step-in and fix things up with their own PRs. My opinion...

If you want "Featured"/"Unfeatured" then you need to propose a change to
Published/Unpublished and Archived/Unarchived

These are all grammatically and functionally wrong

On 24 December 2014 at 13:47, Richard Fath notifications@github.com wrote:

@Hils https://github.com/Hils Well, in my real life job i am also
expert on UX, this is why I meanwhile like it as it is, with
"Featured"/"Unfeatured", i.e. adjectives, because all is clear and
understandable, and the buttons are tiny in every translation as far as I
can see (see also my screenshots above), compared to using the "JUNFEATURE
D" text, which is very long in most translations.

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

"I would not, anyway, like that the concept passes that introducing new code requiring new strings is something reserved to sons and daughters of Albion: everyone with his/her broken English should be"

Totally agree @smz . If we native en-GB speakers and writers really got going according to all the 'rules' we would soon make everything incomprehensible! Which is why I explained the logic behind my personal decision. That was all I intended to do - job done!

... and while we are here talking about languages and the scope of this PR comments has widened, I would like also to express my doubts about the fact that en-GB is official language for Joomla! development. I repeat: this is a doubt, not a proposal for changing things.

Maybe using something simpler and "neutral" (in regard of other languages) could be a good idea. And there are already some good and formally defined alternatives in the form of "controlled languages": one, as an example, is STE (Simplified Technical English) used in the aerospace industry, and another is "Basic English" used by Wikipedia in the "Simple English Wikipedia".

This will not give en-GB an unfair advantage and will probably make life easier for translators teams around world.

en-GB, then, could have his own translators team.

@smz Sorry, it was not my aim to start a "linguistic diatribe".

@richard67 No problem, Richard, really!!

####Archive / Unarchive Vs Archived / Unarchived
Archive is an action so it is used on buttons
Unarchive is an action so it is used on buttons
Archived is a description so it is used in filters and selects
Unarchived is a description so it is used in filters and selects

####Publish / Unpublish Vs Published / Unpublished
Publish is an action so it is used on buttons
Unpublish is an action so it is used on buttons
Published is a description so it is used in filters and selects
Unpublished is a description so it is used in filters and selects

etc

On 24 December 2014 at 14:58, Sergio Manzi notifications@github.com wrote:

@richard67 https://github.com/richard67 No problem, Richard, really!!

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@smz As far as I can see, both @Hills as en-GB and @brianteeman as en-US native speakers want us to use "Feature" and "Unfeature" for the batch action buttons.
And @infograf768 as localization expert suggested the same above.
And meanwhile Brian has commented my PR #5511 in the same way.
I suggest we both change our PRs now to use text JUNFEATURE instead of JUNFEATURED, and you extend this PR here by changing also the old button left beside your new one from text JFEATURED to JFEATURE, so they are all happy and our both PRs can be accepted, and we leave it to the diverse translation teams to find shorter translations as they have now for actions "Featue" and "Unfeature", if possible.
I'll change my PR anyway, but let me know please, Sergio, if you then will do as proposed here, or if we need some new PR for the old button.

P.S.: I really did not want to complicate things, I only tried to help.

I do not speak en-US!!!!!
I am leading the working group to make en-GB better and more consistent.
This PR will not be committed unless the en-GB string is written in correct
en-GB

On 24 December 2014 at 17:15, Richard Fath notifications@github.com wrote:

P.S.: I really did not want to complicate things, I only tried to help.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5485
http://issues.joomla.org/tracker/joomla-cms/5485.

—
Reply to this email directly or view it on GitHub
#5485 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

No problem for me, @richard67: will do. BTW, I strongly suspect @brianteeman being en-GB too...
Only problem I have is that for unknown reasons that I'm trying to identify, my test environment has gone belly up (as I described above), so pleas have some patience as I have to do some

@brianteeman Sorry when I somehow offended you with assuming that you speak en-US, which really can be an offend for British people as far as I remember from my last visit there ;-). I should have checked your location in your profile before (shame, blush, ...). And of course I know about the new work group and your leadership for it.

@richard67 Done! Please check this is what you expected...

@test Tested with success after latest correction.

Result looks on a some 1200px wide screen as shown on following example screenshots for a few languages:

P.S.: Of course I have tested the Hathor view, too. All fine. And consistent with my PR for the featured articvles view. @smz : , perfect

I'm surprised by the fact that Italian is the 2nd most concise language (after English that of course is winning hands down...)

Couldn't we reduce a little bit the width of the "New" button??

Strongly disagree having trash as the last button: easily reachable and too close to "Batch", but I don't have a better proposal either...

@smz On smaller screens reducing the size of the "New" button will not be enough to have a nice display.
I think it will always look a bit messy if not having a very large screen because of this different alignment of the "Help" and "Options" button (right) and the others (left).
Maybe it would look better having the buttons for article creation and treatment and the other 2 for help and options in 2 separate rows (divs), separated by a horizontal line and having a bit padding so the buttons come not too close together, using for both rows the same alignment according to LTR or RTL of the current admin language.
But I think this would be another PR.
What do you think?

@richard67 Absolutely! Mine were just free-flying considerations...

Merry Xmas or whatever to everybody!

Beware if you've been really bad: you'll quickly discover why...

[Image Removed]

Concerning JTOOLBAR_REMOVE, I suggest to keep it as it can be used by 3rd party extensions.

OK here. @brianteeman ?

ok

BTW is there a reason you dont get a message when you feature/unfeature an article - you do when you publish/unpublish

I guess it has never got implemented. It may need a new method in ROOT/libraries/legacy/controller/admin.php or directly in the articles and featured controllers. This would be for another PR.
Merging this one in the mean while.

See #5520 concerning display of a message when setting article(s) to Featured or Unfeatured.