Please do not do this bulk rename. It breaks DocBook generation definitely and completely and means nothing to usability or ease up translation efforts (just renaming for the sake of renaming).
Moreover, it breaks all existing translations for absolutely no reason.
Obviously we won't break the DocBook generation. I don't understand it, though. I was of the impression, that page names didn't matter - only chapter and section names.
Eehmmm. If you rename a page you should fix:
What is the sense then?
Can you explain the sense of this renaming? Is there some algorithm to choose the page name? Should it be an arbitrary unique set of characters? Why not use just "Chapter_1", "Chapter_2", etc. ? (just joking) 
Your first two points goes without saying - we did think of that
The idea of changing page names were made on the assumption, that the DocBook conversion doesn't care about page names - I thought that was the case, so I don't understand why you would need to make a special hack for this. Have I misunderstood your explanation?
The idea of reworking the whole organization of the Amarok Manual including page names is not a new one. It was part of the discussions we had some time ago. For various reasons the process went on hold a bit, but I don't recall anyone expressed misgivings back then - off cause the whole discussion was a bit disorganized, so maybe this was just missed.
Annew and I considered this change because we think that long page names are troublesome (and some of the Amarok page names are really long). Annews main concern is UserBase readers. I actually think they should also be a concern for writers and translators. Shorter links are easier to read (and write) and don't obscure the surrounding text as much as (very) long links.
It is intended to be a "one time only"-affair. In fact I think that not tying page names to the structure of the document is a good thing - that way, if the writers later decides to restructure the manual, they can move pages around by just changing the ToC and PrevNext links - nothing else would need to change.
Off course the advantages of a new naming scheme must be balanced against the work imposed on all of us right now, and if it disrupts the DocBook generation, I doubt it will be worth it to go through with this proposal.
1. I still don't understand. I thought the DocBook didn't care about wiki-pages, but instead organized the book in chapters and sections based on their respective titles. And therefore that in order to make proper links it needs the text to match a title exactly. (To fix terminology in the link [[Special:myLanguage/PageName|PageTitle]] I thought it was PageTitle that mattered to DocBook, not PageName).
2. You are referring to Annew's concern for UserBase users, right? The idea is, that users find long names difficult to remember and bothersome to type. But you might get a better answer from Annew.
As for my own points it's about making the raw wiki text easier to work with for writers and translators and about being prepared for future restructuring.
Still, to me the whole point of having manuals on UserBase is the ability to convert them to DocBook, so the problems you mention speak very strongly against the changes. I would still like to understand exactly how the process works, though. The better we all understand the process, the better we can work to get the best results.
Let me explain more clearly:
My idea is that no user searches for page names. Users search information (keywords) or just read manual section-by-section. Authors just copy and paste names of pages (users may not even know about them).
If I understand you correctly, you are confirming my understanding of the DocBook conversion. But maybe I haven't explained our proposal very well. As an example, we wanted to rename
(as it is called today) to
and change links to that page accordingly, i.e.
would become
(Troubleshooting and Common Problems is the title of the main section of that page). As I see it, DocBook conversion should be unaffected, since the actual title is intact - only the link part would change, or am I missing something?
Off course, this still leaves all the other objections to be carefully considered, even if our plan should turn out not to create problems for the DocBook conversion.
| Current naming scheme | Proposed naming scheme | |
|---|---|---|
| Name of the page | Amarok/Manual/Various/TroubleshootingAndCommonProblems | Amarok/Manual/Troubleshooting |
| Title of the page | Troubleshooting and Common Problems | Troubleshooting and Common Problems |
| DocBook label | troubleshooting-and-common-problems | troubleshooting-and-common-problems |
| Last part of the address (used to find the label) | TroubleshootingAndCommonProblems | Troubleshooting |
| Results | Label (id) found (script assumes that camel-casing can be changed to dashed form) | Label (id) not found (troubleshooting != troubleshooting-and-common-problems) |
| Link in the DocBook | <link linkend="troubleshooting-and-common-problems">Troubleshooting and Common Problems</link> (internal) | <ulink url="http://userbase.kde.org/Amarok/Manual/Troubleshooting">Troubleshooting and Common Problems</ulink> (external) |
So this change effectively breaks almost all internal links for no reason. I still cannot understand why cryptic short names are better than full page name, as my Opera shows (just like modern Firefox and Chrome) just a pleasant short part of the long address in address bar.
Now I get it. Thank for the explanation. The proposed scheme will naturally have to be abandoned. I still wonder, if it is a good idea to have the deep nesting levels of some of the pages, such as
Amarok/Manual/Various/AmarokOnOtherPlatforms/OSX
Maybe it is still a good idea to shorten that to
Amarok/Manual/OSX
That should be OK for DocBook, right? (Off course, there may be other reasons for not doing this.)
Btw., the section name of the OSX page is "Amarok on OS X". Does that not create problems for DocBook? Should we make guidelines for manuals that ensures consistency between ToC, page names and chapter/section titles?
KDE UserBase Wiki 