The point to keep in mind here is that in many cases there won't be a 1:1 replacement, otherwise the current wiki becomes a clone of the old wiki, while I said I wanted to re-arrange stuff so it has a more humane layout (at least imho).
Network configuration was split and is now a bunch of articles since I don't see why someone would want to see 3 meters of scrolling for tables and things to get at what he wanted to do (or we would have to rely on paragraph links which is not good).
I'm doing the same with others (wifi, base-system, whatever), the "overview" page (docs:something:start) is an autogenerated list for the sake of linking the old articles to something until I decide where they can go, but as I said, I would like to not use/rely on that type of structure in the new wiki.
I'm not really looking for overview pages, but for links that are working in their context.
If a link requests specific information that simply isn't there in the requested detail in the replacement link, then there's something wrong.
I frequently need that three meter poster to lookup specific network options and in many cases that monster page was the only authorative documentation source of given parameter.
I agree that this is not the best page to direct people to learn about configuring the network but I do want to keep this technical reference tables around somewhere. Maybe split down into smaller sub-tables / section which can then be included in the various articles.
As I said it's far more involved than just mass-moving internal links, the new wiki structure is different, you can't just mass-rename links and expect 1:1 parity. Any attempt to do so will not be 100% the same as the old link.
My current plan is to read manually all articles and fix links manually (or move around content), which will need time. And since the pages won't be shown in the wiki until I or someone else has reviewed them and fixed the issues, this is not going to affect readers.
The only links that can/should be mass-changed are the ones in device pages or other places that were written following a template and are already shown in the wiki, so you can be sure they were all linking to the same thing.
No, I want to drop the generic info articles I linked. how to interact with bootloaders is useful and isn't easy to find upstream (apart from uboot-maybe).
I've already identified stuff that should go in developer docs, and stuff that is mostly for modding, but there are still articles like I linked above that seem to mostly contain information for the sake of it.
Could you have a look in doc:techref and see if there are articles that we can delete as they are not relevant? I would like to take the occasion to drop the unnecessary articles during the merge.
Otherwise I'm just moving all techref namespace in the docs namespace (so it becomes "docs:techref") with the move plugin, and add an overview page for it.
while we are talking of deleting stuff, there is doc:devel:packages that contains what seems to be an attempt at making a package list, but is pretty old and has been largely superseeded by my system.
If you happen to ssh in the server for other reasons, that part should be deleted manually as there are many articles in that namespace for each package that was indexed.
Today I made all language namespaces accessible again.
Prior to that I noticed during my investigations why things are not working as expected: In the old OpenWrt wiki the language namespaces cz, jp and zh-cn had been manually (and wrongly) added.
Since dokuwiki uses ISO 639-1 language names, the old cz, jp and zh-cn namespaces need to be transfered to cs, ja and zh.
The issue is that they look the same but in actual fact the first link will
redirect the user to the the opener wiki. Which in my case was a dated
page without the LEDE new builds. The latter link has the LEDE builds but
is not the page references from it's own main site https://lede-project.org.
I appreciate the efforts from you and the team with the process of the
merger and would like to help where I can with fixing thsse wiki gaps as
soon as possible to prevent user problems and frustration.
you may not like the decisions that are made, but there will be people who
dislike any decision, but that doesn't mean that you can endlessly debate every
decision. At some point work needs to be done.
Get the content merged and then propose a new look and feel to the content.
Now I think casual contributors can greatly help by doing some of the following:
change the names of the articles (with the "rename page" button on the right, not changing the title) to make sure that the page name has the correct keywords for the search system to find them.
give good descriptive names to all articles
check articles in the same category and merge duplicates or redundant information, dump legacy useless information. (this should be done by people that have some experience in the topic discussed in the article, if you are not sure, don't delete stuff please)
do the same layout treatment to the development guide/documentation as I didn't do much on it because of time constraints.
@jow I've made a UCI networking table cheatsheet here https://openwrt.org/docs/guide-user/network/ucicheatsheet is it OK? does it need all networking UCI options? All UCI options? Using the system suggested by tmomas the table is just pulling the tables from articles, so any edit to the articles will be shown in the table as well
Thanks for the hours of work you put into this!
Not sure if it is a good idea to let casual users do this task. IMO this should be done by us, the documentation team.
A casual user might have a very narrow sight: "This one page must be renamed."
We should have a broader view of the wiki and be looking for systematical naming of the pages.
In addition to this, the wiki admins have access to a statistics plugin which shows a statistic of the searchwords entered into the wiki search: Admin -> Searchword statistic
Yes, it's crude. It lists words, not phrases, splitting "Archer C7" in "Archer" and "C7", making it a bit difficult to interpret what the user has been searching for. However, it gives slight hints to what users are searching for.
Search optimization is a whole topic for itself (and we should probably create a separate new topic for this).
...good names and titles.
I often ask myself, what was page name and what was page title again? page name = the filename, e.g. docs/guide-developer/adding_new_device page title = the thing in bold and big fontsize at the top of the page; in wikisource: "====== Adding a new device ======"
I did run batch-rewriting for a ton of links (mostly about where to find firmware, where is the build system, and other such things) but I haven't finished. I started with the broken links that were present in most pages.
If some links are more important for you, please list them here so I fix them first.