Croatian translation for: 0dyseus@CustomCinnamonMenu, 0dyseus@Desktop…

[muzena]

…Handler, 0dyseus@ExtensionsManager, 0dyseus@PopupTranslator, 0dyseus@QuickMenu, 0dyseus@SysmonitorByOrcus,0dyseus@window-list-fork, betterlock, [email protected], capture@rjanja, CinnVIIStarkMenu@NikoKrause, [email protected], commandLauncher@scollins, computer@brownsr, [email protected], [email protected], [email protected], graphicsCenter@scollins, [email protected], [email protected], IcingTaskManager@json, network@brownsr, officeCenter@scollins, [email protected], placesCenter@scollins, places-with-terminal@mtwebster, [email protected], printers@linux-man, rancher@centurix, restart-cinnamon@kolle, ScreenLocker@tuuxx, Search-box@mtwebster, sessionManager@scollins, sticky@scollins, stopwatch@pdcurtis, system-monitor@pixunil, tfmKeyboard@alexpp, timeout@narutrey, toggle_LookingGlass@kolle, [email protected], weather@mockturtl: update hr.po, WindowListGroup@[email protected]

[jaszhix]

@Odyseus @pdcurtis @Feuerfuchs @sumo @projecthamster @jamesmorgan @gfreeau @linux-man @Centurix @NaruTrey @alexpp @Kolle @pixunil @mbokil

I'm OK with the ITM change, thanks.

[NikoKrause]

Actually it's against the guidelines of contribution to create a pull request for so many applets.
But since it's only adding translation files, I think it's okay.

The Readme of this repo says:

If the changes represent a bug fix, the PR can be merged.
If the changes represent a change in functionality, or in look and feel, or if their implementation could be questioned and/or discussed, the reviewer should leave the PR open and ask the author to review it.

This PR does not change the functionality of any applet. Also it doesn't change the look and feel.
It solves issues for Croation speaking people. So it's some kind of a bug fix.

If one of the authors of these applets has a problem with the translation, he can create a PR, which deletes the file.

@muzena
It's crazy (in a positive way) how many applets you translated at once. Out of curiosity, how long did it take you?

[muzena]

@NikoKrause
43 applets, about 3 days.
It's not so hard since many of the same translated strings are repeated and are similar.
I simply copy translated strings from translation memory.

If I was going to create for each PO file PR, I think it would take longer than the translation.

[JosephMcc]

This probably shouldn't have been merged into xlets with active developers without their approval. That is another good reason for not allowing a PR that affects so many at once. IMHO, a dev shouldn't be forced to make a PR to remove changes they don't want.

[jaszhix]

I think I agree because this means applet authors branches will all have to be re-merged with the base repo again, which adds more inconvenience. I have to resolve a merge conflict.

I think moving the technical upstream is the problem. Its one thing to use a repo as a back end to host the contents of zip files, but having to do everything through git and not a simple zip uploader increased the complexity a lot, means most will be juggling repositories. I would have done this differently.

[pdcurtis]

@jaszhix @JosephMcc @NikoKrause
I do not believe that multiple changes or any changes other than those Essential for a critical security fix should be made without consultation with the author (if active). This is what is in the Readme although I think that should be changed to emphasize the requirement for it being a critical or security nature before a PR is merged without consultation when there is an active developer.

The problem is that and changes can have unintended consequences and apparently 'helpful' and well intended changes made to my applets have actually removed functionality from five applets of my applets - some have been reversed for me but 5 are outstanding and I will probably have to create PLs to reverse them. Worse still is that I only discovered the changes by chance! This is a matter of Trust. If I can not trust that my own applets work as I wrote them (and as their documentation indicates they should work) who else will trust them.

As @jaszhix wrote I would have done this differently but there was no consultation before this was brought in but we now have to live with it and ensure that we all get the benefits the new system should bring but without losing existing applet writers and inhibiting any new writers from starting.

I am putting together some further thoughts which I guess are best raised as an independent issue as this is actually a good example of how cooperation should work and nothing I have said is intended to detract from the valuable work by @muzena - many thanks.

[jaszhix]

I still think more services could be integrated into the repository to restore some of the simpler functionality the zip uploader had. There could be an authenticated way for xlet authors to update their xlet - through the Spices website, and it could overwrite any changes. To do that the server would need to extract the zip, and open an automated PR that would be approved manually for malware checks. Maybe they can update their model to add a field indicating a user is trusted, then it would be automatically merged. Then on approval, it could trigger an event that would overwrite the existing zip file. This would prevent the need for maintaining our own fork, and making sure nothing is conflicting.

It could give some control back to the authors that want it, and preserve this repo as a back-end.

An example repository that has a bot doing this would be jsDelivr. Also see jsDelivr bot.

[clefebvre]

Hi,

First I'd like to say I appreciate the help of people who add translations and fix bugs and I want them to continue to do so without requiring the approval from the author. I think that's important and bug fixers should be empowered, just like authors themselves.

That said, if a mistake is made, it's also EXTREMELY important, we're able (and that includes the author via PR) to revert it. That's not possible if a PR spans across multiple spices.

For this reason I think this particular PR should have been rejected. I don't see any reason to revert it.... but it is hard to review, and if there was anything wrong in it, it would be VERY DIFFICULT for an author to revert the changes on his/her applet without reverting the whole thing.. assuming that's possible.

Now, on the workflow itself... I've talked about it a lot already, both on github and internally.

I do not believe that multiple changes or any changes other than those Essential for a critical security fix should be made without consultation with the author (if active).

Changes should be small and modular, I think we strongly agree on that.

Bug fixes in general, and that includes missing or outdated translations, or changes required as a consequence of changes happening in Cinnamon, or missing core features (highlighting, integration..etc) should be accepted.

This is what is in the Readme although I think that should be changed to emphasize the requirement for it being a critical or security nature before a PR is merged without consultation when there is an active developer.

I disagree. If something is broken and a fix is provided, the interest of the user lies in it being merged.

The problem is that and changes can have unintended consequences and apparently 'helpful' and well intended changes made to my applets have actually removed functionality from five applets of my applets - some have been reversed for me but 5 are outstanding and I will probably have to create PLs to reverse them.

That happens everywhere, but if we can help with that or if there's a case we don't understand, I'd like to know more about this so we can get the opportunity to think about it. Can you explain what happened in details here?

Worse still is that I only discovered the changes by chance! This is a matter of Trust. If I can not trust that my own applets work as I wrote them (and as their documentation indicates they should work) who else will trust them.

That's a workflow issue is it? You can see the git history for your spice.. I don't understand how you wouldn't be able to see that.

In regards to trust, think of it from another point of view. We're the ones distributing that spice. People do not download it from you, they install a Cinnamon spice. When it doesn't work, they think Cinnamon doesn't work. If they report a bug and we think it's important we want to be able to fix it.

As @jaszhix wrote I would have done this differently but there was no consultation before this was brought in but we now have to live with it and ensure that we all get the benefits the new system should bring but without losing existing applet writers and inhibiting any new writers from starting.

It's never nice to lose people and I completely understand your point of view. We've changed things from a real 3rd party collection of applets to something tightly controlling and which removes a lot of power from authors, and you said, it came out of the blue without consultation. I completely understand where you're coming from, and I also understand why some people prefer to leave.

This was necessary though and it's a huge improvement long term for Cinnamon and Cinnamon users, even if we lose quality spices in the process.

We're losing active devs who drive the development of their spices in isolation, some of them really good spices. We're also opening up and making it easier for other people to bug fix and contribute though. Look at all these translations, we'd never have seen that on so many spices before. And when the time comes to add new features into Cinnamon we'll be able to add support to all spices as well, ourselves, and that's a huge improvement as well.

In regards to consultation, it was brutal and I'm sorry and it had to be done in secrecy. You might remember that uploading was closed down temporarily before the new workflow was ready. We talked about it for weeks internally but I couldn't leak the info. I don't know if you're aware of it, but we're targeted specifically and in terms of security Cinnamon Spices were a huge Achilles Heel. We're quite lucky nobody used it to upload malicious code, it was a catastrophe waiting to happen. After we were targeted and this security hole was identified, this change of workflow had to happen urgently and it's a huge relief to see it implemented.

[pdcurtis]

@clefebvre Thanks for the clarifications,in particular the reasoning behind the changes had to be brought in.
As far as the changes to 5 of my applets, that was a multiple change #148 which was made to tidy up the placement of README.md and changelog files which in my case moved them all from the applet folder to a higher level. Unfortunately in my case I had my helpfiles and changelogs where accessible from within the applets from a sub-menu of the context (right click menu) so they could be read easily by the user without going to the repository or the cinnamon spices web site. I therefore have near identical README.md files in two places.

As far as not seeing the changes: That was because the Pull Request did not mention specific authors so I was not notified or the fact that it was moving changelog files as well as the README.md files which I had already put in the correct place so there was nothing to alert me to changes. At the time I was using expensive mobile or satellite connections so I was not looking in detail at the repositories unless there was a need so the first time I saw a problem was when I used the facility on my own applet and it did not work.

That sort of problem should not happen again as it is stressed in many places that the author must be mentioned by a @author to ensure he is notified and the dangers of multiple updates are now appreciated.

I like to think my applets are better documented than most but they also include a number of workarounds to get round some previous problems in cinnamon/mint/ubuntu which were beyond our control (for example see Cinnamon segfault issue 2835) where only those involved would understand the reasons for odd coding in my applet! There are many things I would do differently starting now but it would take a lot of time and testing to tidy up an old applet proven over many versions of Cinnamon and my fear is that risks outweigh the advantages. If it ain't broke don't fix it.

In my post above I also said I was putting together some further thoughts on Trust and I finally put some into your article on Segfault on Changes to cinnamon spices for developer and artists which I will repeat below.

I believe Applets need some form of score to replace the old user comments and ranking so a user knows he can trust that they will be useful, do what they say and not damage his system.
I have put some thought into this over the last few weeks and to start discussion going I put forward the suggestion that some factors are

• Author (identified and currently committed to development and maintenance – 3),
• Documentation (description, rationale, help, version history etc – 3),
• Status/Maturity (time available and number of releases, alpha, beta, released etc – 3),
• Best Practice (Follows coding guidelines, commented or documented code so it can be followed and checked, consistency of interface with rest of Cinnamon, compatibility with a range of themes) – Difficult to give a max score as this will always be a moving target so say 2
• Independent Assessment/Support (Do other trusted people support, check code, test and vouch for functionality – ?? ).
• Extra points perhaps for translation support (1) and other things I have not thought about.

The above are in approximate order of progression that a new author and applet might reasonably achieve. If the first five are given 3 points a score of over say 10 should give confidence for to any normal user to install and full house should be at least as trustworthy as system applet – lower scores imply that a user should do some preparation and be sure it is useful to them or wait until it is further developed.
Who should do the initial scoring? Probably the author – I have found managing people they usually assess their own work lower than their managers and you need to trust the author in any case. Obviously the team would spot big anomalies and could ask the author to justify his score.

I also believe that the first time an applet is installed it should be via the spices web site otherwise there is no information available to advise the user who may just experiment without realising that other software may need to be installed or that some applets are only relevant to certain hardware configurations.