Differences between revisions 1 and 66 (spanning 65 versions)
Revision 1 as of 2019-08-15 19:49:10
Size: 703
Editor: nodiscc
Comment: add maintenance tools links
Revision 66 as of 2019-09-14 14:55:20
Size: 15126
Editor: nodiscc
Comment: reply @BeatriceTorracca
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
== nodiscc ==
Line 14: Line 13:
 * ''[[PackageManagement]]'' (portal)
 * ''[[Software]]'' (portal)
 * ''[[SystemAdministration]]'' (portal)
 * ''[[DebianInstaller/Preseed]]''
 * ''[[Packaging]]'' (portal)
 * ''[[Sound]]'' (portal)
 * ''[[Firefox]]''
 * ''[[Multimedia]]'' (portal) (from https://salsa.debian.org/nodiscc2-guest/awesome-linuxaudio)



----
Line 18: Line 30:
 * Macros: {{{DebPkg:}}}, {{{DebMan:1}}}  * RandomPage
* Macros: {{{DebPkg:}}}, {{{DebMan:bash.1|bash}}}
Line 20: Line 33:
 * Add Wikipedia links if relevant

  
=== Work in progress ===

 * AptConfiguration
 * PackageManagementTools
 * [[DebianFirewall]], [[Firewalls]]
 * [[BTS]], [[bugreport]]
 * Add Arch Wiki links if relevant
 * ''[[Printing]]'' (portal)
 * [[RemoteDesktop]], [[VNC]]...
 * ''[[CommandLineInterface]]'' (portal)
 * ''[[SecurityManagement]]'' (portal)
 * ''[[Network]]'' (portal)


'''Obsolete pages:''' <<FullSearch(CategoryObsolete)>>

'''Redundant pages:''' <<FullSearch(CategoryRedundant)>>


=== Wiki engine bugs ===

 * `zh_CN` `bn`, `ta` are not recognized as valid language tags by the search engine: see [[Network]] where `bn`, `zh_CN` and `ta` pages still show in the `FullSearch` macro despite restricting it to english pages. On FindPage there are no entries for Bengali and Simplified Chinese in the language selection box. Also `pt_BR` does not work for Brazilian Portuguese (only `pt-br`) -> bug not listed on https://moinmo.in/MoinMoinBugs -> how to fix?
 * May not be a bug, and not too annoying: False positives on Category pages, when a page contains (anywhere, and not at bottom of the page) a wiki link to that category.

=== Talks ===

{{{#!wiki yellow/solid
Hi nodiscc,

It looks like you have some good plans against the wiki mess, I haven't followed the details but I can only agree with the cleaning work, orphaned pages, not categorized ones, duplicate ones and what else.
If you want we can discuss this somewhere, it might help if we're several agreeing on what needs to be done.

See you!

ccts
}}}
{{{#!wiki green/solid
Hi ccts, for many years I found it was hard to search for information on the debian wiki, pages are not discoverable, many pages were drafts, there was duplicate/contradictory information... so recently I started following some broad guidelines:

 * Make the wiki more readable, navigable, accessible, refresh some older content
 * Deduplicate/merge content across pages on topics I understand, or use links.
 * Merge pages that have almost no content with their "parent" page, in general avoid creating extra pages when the content could fit in an existing page. No one will maintain them.
 * Standardize portals, use them as landing pages that any user from any knowledge level can understand and find information from.
 * Add categories to all pages, Redirect CategoryCategory pages to their respective portal, add `fullsearch` macros for the Category on the portal page
 * Standardize page names/formatting, spacing, link syntax, link cleanup... (EditorGuide)
 * I have amassed a good amount of Debian docs on a personal wiki, wanted to merge some of it here, but couldn't cleanly do it without some refactoring (still ongoing)
 * Everything linked from FrontPage should be high quality content
 * There is some good general advice at https://wiki.c2.com/?GoodStyle https://wiki.c2.com/?RefactoringWikiPages
 * Delegate explanation/description of general concepts to Wikipedia (copy intro, link to WP page)
}}}
{{{#!wiki yellow/solid
:) I gave fullsearch a try to (see [[Game]] page for an illustration), so we're on the same line.
 * You may use the Cached version when you think you're done with the category. I admit I don't remember when the cache gets regenerated unless you explicitly click to do it.
 * You may add the lang:en search parameter, which means translators also have to replace it with the right one. That also means categories which are named after a language shouldn't exist (only some french ones existing IIRC).

Using fullsearch has a few drawbacks, some Debian wiki pages mostly contain list of software, with comments... (lists with `DebPkg` shortcut) so if you switch to a `FullSearch` list, you won't be able to put comments on each line. Some people used them to "recommend" some packages over others but I don't think this should be the main purpose of a wiki.
Also, making lists is the purpose of categories, so logically, pages shouldn't need the fullsearch macro to do that, and people would navigate using the categories. Right now there are a few redirections (url rewrite in wiki admin?), I believe they could be removed if we want to give back their purpose to categories.

Right now I have no big idea, maybe I'll do nothing but if I attempt to join your efforts :) I may have an eye on the orphaned pages, as there should be none IMO.
I also feel some pages content turned quite old or irelevant so we don't have to hesitate too much to delete their content.
That's what I think you have been doing so it's probably no big news.

I'm unsure these wiki issues have been discussed within Debian lately, I'm not part of any team, this should also clarify my words are in no way something official :)

See you!}}}

{{{#!wiki green/solid
 . You may use the Cached version when you think you're done with the category
 . add the lang:en search parameter

Good, I will do that.

 . some Debian wiki pages mostly contain list of software, with comments... (lists with `DebPkg` shortcut) so if you switch to a `FullSearch` list, you won't be able to put comments on each line.

I will probably not switch those pages, I mainly user `FullSearch` on portals:

 * Each page is attached to one or more categories
 * Each Category page redirects to the corresponding portal
 * The portal has plain paragraphs that introduce common topics; these paragraphs, in turn link the detailed pages about the subject.
 * At the bottom of the portal there is a `FullSearch` for the corresponding category - this ensures less frequent topics are also visible and discoverable from the portal - and can be later merged, or improved. Or a proper paragraph/link can be added to introduce them.

We ''could'' use Category pages for this, but far less people will visit them, and it takes more maintenance. `FullSearch` on the corresponding portal is much more visible, and it "forces" us to keep the page list clean/short - something `lang:en` and the current cleanup will help solving. See for example CommandLineInterface where it makes content duplication/too many pages symptom very evident.

When all pages from a category are cleanly linked from the corresponding portal page, `FullSearch` is indeed not needed. But this is almost never the case.

 . we don't have to hesitate too much to delete their content

I read each candidate for deletion completely to make sure no interesting content would be lost, and move it to other pages if needed.

 . I'm unsure these wiki issues have been discussed within Debian lately

I left a message on #debian-www IRC about this, and no one seems to disagree (got no answer at all :) ). So I guess it's fine, as long no one reverts my changes :)

A plus!

The [[Game]] page looks great!
}}}

{{{#!wiki pink/solid
 . I left a message on #debian-www IRC about this, and no one seems to disagree (got no answer at all :)

You didn't stick around long enough for anyone to comment. Please keep your IRC client in the #debian-www channel and join the debian-www mailing list, there has been at least one discussion about you there:

https://lists.debian.org/msgid-search/06092019183508.5a8f735e9444@desktop.copernicus.org.uk
}}}

{{{#!wiki yellow/solid
Some more thoughts, I have mixed feelings about the "Portals" idea.

1) I believe the most common way for people to navigate is by doing a search, rather than going through portals to find infos.
By the way, is it only me, or the Title/Text buttons resize when you click on them? (using Firefox).

2) If I refer to the wiki homepage, there are 2 pages I feel like I'd want to click, Desktop and eventually Software (only eventually, maybe because I already know this page likely doesn't contain the kind of informations I'm looking for). Talking for me of course, some people might find the "News" link very handy, or others, I don't know.

My point is most people might just skip the portals, so i'm not sure it's right to make it look like they're central parts of the wiki. They might be good guidance for some users new to Debian, but they might be overwhelming too (in particular, I don't find the intro and the tables full of links very useful).

Anyway, both is very fine to me :), and it's not wrong either to bring these portals one step further, since they are already here. Cleaning already makes most of the job.
}}}

{{{#!wiki blue/solid
@ccts I agree with everything you said. Portals have 2 valid uses:
 * discover the wiki by following links from the front page
 * serve as a CategoryCategory with better presentation/wording than a simple list of page (show basic info on a general topic, list related pages from simple to complex)

A good category system helps discoverability (and when the search does not return good results, which is often for me), and keeping/managing reasonable inventories of pages.

But I agree that it should not be a central part, navigation should use interpage links and good page names/search results as much as possible. There are too many portals/categories, and the presentation is debatable (the fancy table is harder to maintain than a plain list, there is too much whitespace...).

At the moment they help me tracking work on other pages, but I'm all for cutting down their number/simplifying them. On FrontPage, there are 14 portals listed, which is reasonable, but there are actually many more CategoryPortal pages.

For example, CategoryNetworkApplication should just be CategorySoftware + CategoryNetwork. CategoryWebBrowser is too specific IMHO..., etc.

I'll keep trimming down outdated/too verbose/duplicate/"leaf" pages and hopefully we'll have a clearer view of how to do the rest.

https://i.giphy.com/media/l2QEgWxqxI2WJCXpC/giphy.gif

Cheers

}}}

{{{#!wiki pink/solid
 
I have made a comment at
https://lists.debian.org/msgid-search/09092019113222.e95b097fea94@desktop.copernicus.org.uk

--
Brian.
}}}

{{{#!wiki blue/solid
 
I'm wondering what the collection of links are useful for? Instead,
please read the content and decide if it's still valid or usefull. For
e.g. there were two pages, completly useless which you have added to
the sysadmin portal:

Backup/Creating_A_Tar_Backup_Onto_LS120_Laser_Servo_Diskettes

Backup/Restoring_A_Tar_Backup_From_LS120_Laser_Servo_Diskettes

Quality instead of quantity!
--
Thomas
}}}

{{{#!wiki yellow/solid

Hi Thomas,

please have a look at this mailing list thread:

 * https://lists.debian.org/debian-www/2019/09/msg00021.html
 * https://lists.debian.org/debian-www/2019/09/msg00022.html
 * https://lists.debian.org/debian-www/2019/09/msg00028.html

Ths list of links is generated automatically from pages in the CategorySystemAdministration category. If they are not relevant, please fix these pages or delete them. Deleting the Restoring_A_Tar_Backup... pages was the right thing to do. Having the pages list in plain sight will help us cleaning up the sysadmin category.

I expect the SystemAdministration page to link to all relevant wiki pages; feel free to add proper descriptions/sections to the portal to gradually replace the raw list of pages. Once they're all listed we can safely disable the search macro.

> Instead, please read the content and decide if it's still valid or usefull

I'm in the process of doing that, but can't review all old wiki pages (there are many) by myself. Your help is welcome.

> Quality instead of quantity!

Definitely.

}}}

{{{#!wiki white/solid
 
Hi, please unless you have some specific reason, don't do changes like the following one to the translated pages.

https://wiki.debian.org/it/ShellIntroduction?action=diff&rev1=6&rev2=7

In this way you break the correspondence between the contents of the original and the translated pages. Probably the better option would be to leave the work to the translator. Otherwise just make the translated page a redirect to the translation of the newEnglish page if it exist. In this case it would be it/CommandLineInterface and I already created the redirect.

Another thing, since some translation might exist and some not, and also some external pages could have a link to some wiki pages, I think the best option (and the traditional course of action) would be to not simply delete pages (like I think you did with ShellIntroduction), but make them a redirect to another page. This also goes for renaming. You rename an old page to a new name and also create a new page with the old name which is simply a redirect to the new name.

This are just my 2 cents of course, but since I try to keep Italian translations updated I would appreciate if you take my opinion into consideration

Beatrice
}}}


{{{#!wiki yellow/solid
 
Hi Beatrice,
I will do as you suggested and leave redirects instead of simply deleting pages/updating links on translated pages. If there's a good reason to delete a page I'll contact you beforehand.

Thanks for the heads up

nodiscc
}}}


{{{#!wiki white/solid

Thanks a lot. And thanks for all the work on the wiki pages

beatrice
}}}

{{{#!wiki white/solid

Yes, I am sorry to stress this point again, but deleting pages has an enormous effect on translations. See the example of SourcesList. I knew I was in sync with version 88. To update my translation I just had to retrace all the changes in the history from v.88 onwards and apply them to my translation. Now if I look at the page history https://wiki.debian.org/SourcesList?action=info all the history before your deletion is lost and basically I have to retranslate the whole page or at the very list recheck it completely.

I would be grateful if you could not delete/restart pages but kept the history (in a way I also think it is good practice to keep the old versions archived).

beatrice
}}}

{{{#!wiki yellow/solid
@Beatrice, sorry again for the inconvenience; to give you a hint if you want to update AptSources translations, I think I only rewrote up to to ''sources.list format'' section.

I will take extra care not to destroy page history in the future
}}}
Line 22: Line 276:
## Uncomment the next line if you are a wiki translator
## CategoryWikiTranslator


Wiki consolidation/cleanup/maintenance

Work in progress

Obsolete pages:

Redundant pages:

  1. AlsaMidi
  2. AptMove
  3. BTS/BugTag
  4. BTS/HowTo
  5. Backup
  6. BackupAndRecoveryWork
  7. Bash
  8. BourneShell
  9. BrowserApps
  10. BugReport
  11. BugReport/WorkingOn
  12. BugTriage
  13. CategoryRedundant
  14. CommandLine
  15. CommandsCLI
  16. DebianFirewall
  17. DebianInstaller/SataRaid
  18. DebianInstaller/SoftwareRaidRoot
  19. DebianSoftware
  20. DebianWiki/Administration
  21. DefaultWebBrowser
  22. EduCheesetracker
  23. EduSoundtracker
  24. Firefox
  25. Firewalls
  26. HowToPackageForDebian
  27. HowtoUseBTS
  28. Icedove
  29. JabberClients
  30. LCD
  31. Linux volume management
  32. LinuxRaidForAdmins
  33. Manual-Howto
  34. MidiHardware
  35. Mozilla
  36. MultimediaCodecs
  37. NetworkApplication
  38. NetworkFAQ
  39. Part-UUID
  40. Peer2Peer
  41. QuickInstall
  42. RemoteFiles
  43. ShellCommands
  44. ShellConfiguration
  45. ShellTricks
  46. SoftwareRAID
  47. Tar
  48. TheUnixWay
  49. UserInterface
  50. WHEEL/PAM
  51. WindowsEquivalent
  52. XCP
  53. Zg2ShellStartup
  54. ar/CommandLineInterface
  55. bn/CommandLineInterface
  56. ccts
  57. coreutils
  58. de/Manual-Howto
  59. de/NetworkApplication
  60. deb
  61. es/CommandLineInterface
  62. es/TheUnixWay
  63. fr/Bash
  64. fr/HowtoUseBTS
  65. fr/ShellTricks
  66. fr/TheUnixWay
  67. ftp.debian.org
  68. id/CommandLineInterface
  69. it/BTS/HowTo
  70. it/Bash
  71. it/CommandLine
  72. it/CommandsCLI
  73. it/DebianFirewall
  74. it/DebianSoftware
  75. it/Firefox
  76. it/Firewalls
  77. it/HowToPackageForDebian
  78. it/JabberClients
  79. it/Manual-Howto
  80. it/MultimediaCodecs
  81. it/NetworkApplication
  82. it/Part-UUID
  83. it/Peer2Peer
  84. it/QuickInstall
  85. it/RemoteFiles
  86. it/ShellCommands
  87. it/ShellConfiguration
  88. it/ShellTricks
  89. it/TheUnixWay
  90. it/UserInterface
  91. it/WindowsEquivalent
  92. it/coreutils
  93. it/deb
  94. it/rootfs
  95. ko/CommandLineInterface
  96. ms/CommandLineInterface
  97. nodiscc
  98. pamusb
  99. partclone
  100. pt_BR/BTS/BugTag
  101. pt_BR/BTS/HowTo
  102. pt_BR/Bash
  103. pt_BR/BugReport
  104. pt_BR/DebianInstaller/SataRaid
  105. pt_BR/Firefox
  106. pt_BR/HowToPackageForDebian
  107. pt_BR/Part-UUID
  108. pt_BR/QuickInstall
  109. pt_BR/ShellCommands
  110. pt_BR/TheUnixWay
  111. pt_BR/deb
  112. rootfs
  113. ru/CommandLineInterface
  114. ru/Part-UUID
  115. sv/CommandLineInterface
  116. uk/RemoteFiles
  117. uk/WikiTag
  118. vi/commandlineinterface
  119. zh_CN/CommandLineInterface
  120. zh_CN/HowToPackageForDebian
  121. zh_CN/Manual-Howto

Wiki engine bugs

  • zh_CN bn, ta are not recognized as valid language tags by the search engine: see Network where bn, zh_CN and ta pages still show in the FullSearch macro despite restricting it to english pages. On FindPage there are no entries for Bengali and Simplified Chinese in the language selection box. Also pt_BR does not work for Brazilian Portuguese (only pt-br) -> bug not listed on https://moinmo.in/MoinMoinBugs -> how to fix?

  • May not be a bug, and not too annoying: False positives on Category pages, when a page contains (anywhere, and not at bottom of the page) a wiki link to that category.

Talks

Hi nodiscc,

It looks like you have some good plans against the wiki mess, I haven't followed the details but I can only agree with the cleaning work, orphaned pages, not categorized ones, duplicate ones and what else. If you want we can discuss this somewhere, it might help if we're several agreeing on what needs to be done.

See you!

ccts

Hi ccts, for many years I found it was hard to search for information on the debian wiki, pages are not discoverable, many pages were drafts, there was duplicate/contradictory information... so recently I started following some broad guidelines:

  • Make the wiki more readable, navigable, accessible, refresh some older content
  • Deduplicate/merge content across pages on topics I understand, or use links.
  • Merge pages that have almost no content with their "parent" page, in general avoid creating extra pages when the content could fit in an existing page. No one will maintain them.
  • Standardize portals, use them as landing pages that any user from any knowledge level can understand and find information from.
  • Add categories to all pages, Redirect CategoryCategory pages to their respective portal, add fullsearch macros for the Category on the portal page

  • Standardize page names/formatting, spacing, link syntax, link cleanup... (?EditorGuide)

  • I have amassed a good amount of Debian docs on a personal wiki, wanted to merge some of it here, but couldn't cleanly do it without some refactoring (still ongoing)
  • Everything linked from FrontPage should be high quality content

  • There is some good general advice at https://wiki.c2.com/?GoodStyle https://wiki.c2.com/?RefactoringWikiPages

  • Delegate explanation/description of general concepts to Wikipedia (copy intro, link to WP page)

:) I gave fullsearch a try to (see Game page for an illustration), so we're on the same line.

  • You may use the Cached version when you think you're done with the category. I admit I don't remember when the cache gets regenerated unless you explicitly click to do it.
  • You may add the lang:en search parameter, which means translators also have to replace it with the right one. That also means categories which are named after a language shouldn't exist (only some french ones existing IIRC).

Using fullsearch has a few drawbacks, some Debian wiki pages mostly contain list of software, with comments... (lists with DebPkg shortcut) so if you switch to a FullSearch list, you won't be able to put comments on each line. Some people used them to "recommend" some packages over others but I don't think this should be the main purpose of a wiki. Also, making lists is the purpose of categories, so logically, pages shouldn't need the fullsearch macro to do that, and people would navigate using the categories. Right now there are a few redirections (url rewrite in wiki admin?), I believe they could be removed if we want to give back their purpose to categories.

Right now I have no big idea, maybe I'll do nothing but if I attempt to join your efforts :) I may have an eye on the orphaned pages, as there should be none IMO. I also feel some pages content turned quite old or irelevant so we don't have to hesitate too much to delete their content. That's what I think you have been doing so it's probably no big news.

I'm unsure these wiki issues have been discussed within Debian lately, I'm not part of any team, this should also clarify my words are in no way something official :)

See you!

  • You may use the Cached version when you think you're done with the category
  • add the lang:en search parameter

Good, I will do that.

  • some Debian wiki pages mostly contain list of software, with comments... (lists with DebPkg shortcut) so if you switch to a FullSearch list, you won't be able to put comments on each line.

I will probably not switch those pages, I mainly user FullSearch on portals:

  • Each page is attached to one or more categories
  • Each Category page redirects to the corresponding portal
  • The portal has plain paragraphs that introduce common topics; these paragraphs, in turn link the detailed pages about the subject.
  • At the bottom of the portal there is a FullSearch for the corresponding category - this ensures less frequent topics are also visible and discoverable from the portal - and can be later merged, or improved. Or a proper paragraph/link can be added to introduce them.

We could use Category pages for this, but far less people will visit them, and it takes more maintenance. FullSearch on the corresponding portal is much more visible, and it "forces" us to keep the page list clean/short - something lang:en and the current cleanup will help solving. See for example CommandLineInterface where it makes content duplication/too many pages symptom very evident.

When all pages from a category are cleanly linked from the corresponding portal page, FullSearch is indeed not needed. But this is almost never the case.

  • we don't have to hesitate too much to delete their content

I read each candidate for deletion completely to make sure no interesting content would be lost, and move it to other pages if needed.

  • I'm unsure these wiki issues have been discussed within Debian lately

I left a message on #debian-www IRC about this, and no one seems to disagree (got no answer at all :) ). So I guess it's fine, as long no one reverts my changes :)

A plus!

The Game page looks great!

  • I left a message on #debian-www IRC about this, and no one seems to disagree (got no answer at all :)

You didn't stick around long enough for anyone to comment. Please keep your IRC client in the #debian-www channel and join the debian-www mailing list, there has been at least one discussion about you there:

https://lists.debian.org/msgid-search/06092019183508.5a8f735e9444@desktop.copernicus.org.uk

Some more thoughts, I have mixed feelings about the "Portals" idea.

1) I believe the most common way for people to navigate is by doing a search, rather than going through portals to find infos. By the way, is it only me, or the Title/Text buttons resize when you click on them? (using Firefox).

2) If I refer to the wiki homepage, there are 2 pages I feel like I'd want to click, Desktop and eventually Software (only eventually, maybe because I already know this page likely doesn't contain the kind of informations I'm looking for). Talking for me of course, some people might find the "News" link very handy, or others, I don't know.

My point is most people might just skip the portals, so i'm not sure it's right to make it look like they're central parts of the wiki. They might be good guidance for some users new to Debian, but they might be overwhelming too (in particular, I don't find the intro and the tables full of links very useful).

Anyway, both is very fine to me :), and it's not wrong either to bring these portals one step further, since they are already here. Cleaning already makes most of the job.

@ccts I agree with everything you said. Portals have 2 valid uses:

  • discover the wiki by following links from the front page
  • serve as a CategoryCategory with better presentation/wording than a simple list of page (show basic info on a general topic, list related pages from simple to complex)

A good category system helps discoverability (and when the search does not return good results, which is often for me), and keeping/managing reasonable inventories of pages.

But I agree that it should not be a central part, navigation should use interpage links and good page names/search results as much as possible. There are too many portals/categories, and the presentation is debatable (the fancy table is harder to maintain than a plain list, there is too much whitespace...).

At the moment they help me tracking work on other pages, but I'm all for cutting down their number/simplifying them. On FrontPage, there are 14 portals listed, which is reasonable, but there are actually many more CategoryPortal pages.

For example, CategoryNetworkApplication should just be CategorySoftware + CategoryNetwork. CategoryWebBrowser is too specific IMHO..., etc.

I'll keep trimming down outdated/too verbose/duplicate/"leaf" pages and hopefully we'll have a clearer view of how to do the rest.

https://i.giphy.com/media/l2QEgWxqxI2WJCXpC/giphy.gif

Cheers

I'm wondering what the collection of links are useful for? Instead, please read the content and decide if it's still valid or usefull. For e.g. there were two pages, completly useless which you have added to the sysadmin portal:

Backup/Creating_A_Tar_Backup_Onto_LS120_Laser_Servo_Diskettes

Backup/Restoring_A_Tar_Backup_From_LS120_Laser_Servo_Diskettes

Quality instead of quantity! -- Thomas

Hi Thomas,

please have a look at this mailing list thread:

Ths list of links is generated automatically from pages in the CategorySystemAdministration category. If they are not relevant, please fix these pages or delete them. Deleting the Restoring_A_Tar_Backup... pages was the right thing to do. Having the pages list in plain sight will help us cleaning up the sysadmin category.

I expect the SystemAdministration page to link to all relevant wiki pages; feel free to add proper descriptions/sections to the portal to gradually replace the raw list of pages. Once they're all listed we can safely disable the search macro.

> Instead, please read the content and decide if it's still valid or usefull

I'm in the process of doing that, but can't review all old wiki pages (there are many) by myself. Your help is welcome.

> Quality instead of quantity!

Definitely.

Hi, please unless you have some specific reason, don't do changes like the following one to the translated pages.

https://wiki.debian.org/it/ShellIntroduction?action=diff&rev1=6&rev2=7

In this way you break the correspondence between the contents of the original and the translated pages. Probably the better option would be to leave the work to the translator. Otherwise just make the translated page a redirect to the translation of the newEnglish page if it exist. In this case it would be it/CommandLineInterface and I already created the redirect.

Another thing, since some translation might exist and some not, and also some external pages could have a link to some wiki pages, I think the best option (and the traditional course of action) would be to not simply delete pages (like I think you did with ?ShellIntroduction), but make them a redirect to another page. This also goes for renaming. You rename an old page to a new name and also create a new page with the old name which is simply a redirect to the new name.

This are just my 2 cents of course, but since I try to keep Italian translations updated I would appreciate if you take my opinion into consideration

Beatrice

Hi Beatrice, I will do as you suggested and leave redirects instead of simply deleting pages/updating links on translated pages. If there's a good reason to delete a page I'll contact you beforehand.

Thanks for the heads up

nodiscc

Thanks a lot. And thanks for all the work on the wiki pages

beatrice

Yes, I am sorry to stress this point again, but deleting pages has an enormous effect on translations. See the example of SourcesList. I knew I was in sync with version 88. To update my translation I just had to retrace all the changes in the history from v.88 onwards and apply them to my translation. Now if I look at the page history https://wiki.debian.org/SourcesList?action=info all the history before your deletion is lost and basically I have to retranslate the whole page or at the very list recheck it completely.

I would be grateful if you could not delete/restart pages but kept the history (in a way I also think it is good practice to keep the old versions archived).

beatrice

@Beatrice, sorry again for the inconvenience; to give you a hint if you want to update AptSources translations, I think I only rewrote up to to sources.list format section.

I will take extra care not to destroy page history in the future


CategoryHomepage