Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• Archives

Translation(s): none

• Please don't update this page. It's only a snapshot of discussion historics.

• See ["DebianWiki/ConventionsDiscussion"]

  ?TableOfContents(2)

?Anchor(image)

Images

What is the concept of the image database (["Portal/IDB"])? Are these images to be used in every NewPage or just in the portals? ?BRI ask this question because I just modified Portail_Accueil to correct the problem with the images used.?BR And then I checked all the new material about this wiki organisation: DebianWiki, DebianWiki/EditorGuide (great work! this wiki really needs this type of organisation) and found the ["Portal/IDB"]... so:

• was my initial modification incorrect? was the fact that image links were bad ok?

  • -- EricVeirasGalisson ?DateTime(2007-11-12T21:05:58Z)

-- SalokineTerata ?DateTime(2007-11-12T23:22:39Z)

• Hi EricVeirasGalisson and thank you for your corrections. Yes Portal/IDB is a central workspace for portal only. It's useful to maintain translated portal versions. Concerning articles, perhaps, we may define to store image (logo and icones only) in the referent article (english version) ? Screenshot are using translated interfaces, so we can't centralize them. Bye.

-- -- FranklinPiat ?DateTime(2007-11-13T00:17:34Z)

• Hi, IMHO, Images that belongs to DebianWiki's theme should be served as static content (i.e from http://wiki.debian.org/htdocs/''common''/img/ ). -> for performance and to make sure they are rad-only. (once we will have a stable list we'll submit to Erinn... we can still wait a few months.). Other image should be attached the the page, since I guess that if an image is reused, the text next to it is probably duplicated too.

  • Ok, so for the portal page ["Portail_Accueil"] (note: this non-CamelCase pagename is not easy to use...), I'll remodify the links to use the images from Portal/IDB.

    • -- EricVeirasGalisson ?DateTime(2007-11-13T10:14:27Z) (I prefer to put my signature after my comment, you seems to prefer before, any reason why?)

-- SalokineTerata ?DateTime(2007-11-13T15:50:49Z)

• EricVeirasGalisson: ["Portail_Accueil"] will be renamed ["PageD'Accueil/Testing"]. If you want, you can begin to sync this portal with english version ["FrontPage/Testing"]. Don't sync sub-portals because it's not stabilized. About your signature, don't worry, it's not a probleme. personnaly I prefer to know who before what. Thanks for your contribution.

  FranklinPiat: Yes it's a good idea to do it when definitive release will be published. Maybe we can contact ErinnClark to introduce this proposition ? (I notify him) Bye.

  • SalokineTerata: what do you mean by syncing ["Portail_Accueil"] and ["FrontPage/Testing"] (now ?FrontPage/PortalProposal):

• the French page must be changed to conform to the English one?
  • Yes. French layout is very very out of date

• the text from JoeyHess in the comment section of the English page need translation?

  • Yes,I think
• the English version format is outdated and need to be made like the French one to conform to what seems the new style for Portal pages?
  • English version is the referent format. Just tell me and i will try to find some time to do the job.

    • -- EricVeirasGalisson ?DateTime(2007-11-24T17:13:08Z)

-- SalokineTerata ?DateTime(2007-11-24T18:31:23Z)

• Hi, My answer in your text. If you want to help us, we can work together to define more task on ["DebianWiki/Administration"]

  Bye

  • I've synced the two pages:
    • A relecture of my traduction (especially the comment part) may be necesary.

    • a French ?DefaultInclude version is needed, what is the prefered name: ?FrDefaultInclude?

    This page (?ConventionsDiscussion) is normally dedicated to Conventions discussion, so where is better to talk to organise the job (maybe DebianWiki/Administration/Discussion ?)

    • bye -- EricVeirasGalisson ?DateTime(2007-11-25T17:42:08Z)

-- SalokineTerata ?DateTime(2007-11-25T18:13:10Z)

• Yes very good job.

  At this moment, name of translated pages is analysis in progress (see ["DebianWiki/TranslationNamespace"]). Read this and give your opinion.

  Yes ["DebianWiki/Administration"] is a good place to coordonate our works (especially Current tasks section) Bye.

Policy suggestion #1

-- SalokineTerata ?DateTime(2007-11-24T11:32:09Z)

• Insert DebianWiki's theme should be served as static content to [:DebianWiki/Administration#todo:Administration task]

Homepage

-- SalokineTerata ?DateTime(2007-11-11T22:06:51Z)

• Why not ? (homepage other other than Debian official stuff)

-- -- FranklinPiat ?DateTime(2007-11-13T00:17:34Z)

• We should carefully choose what is highlighted. To many highlighted stuffs are just confusing.

-- SalokineTerata ?DateTime(2007-11-13T15:50:49Z)

• Yes too informations kill information Look at ["Synaptic"] to illustrate my proposition. Synaptic it's not an official Debian projet, but, I think it's easy for user to find official hompepage about it.

Policy suggestion #1

-- SalokineTerata ?DateTime(2007-11-24T11:32:09Z)

• Homepage is presented in the External Links or See also sections of the page.

Footer, category and portal

• Hi Salokine,

  I have noticed you create a lot of links at the bottom of pages. Wouldn't it be better to use 1) CategoryXXXX or 2) a link in "See Also" section ?

FranklinPiat ?DateTime(2007-12-12T21:35:32Z)

• Hi, Consider Portal as Category so I flag page with it (as parent page). Maybe we can create virtual Category pointing to each portal.(See also is for "connexe" information. )

• Example: ?CategorySofware contain a #redirect to "Software"

Next, we can flag page with ?CategorySofware and not directly with "Software"

Bye. -- SalokineTerata ?DateTime(2007-12-12T22:10:38Z)

• Salokine, This seems a good solution.

FranklinPiat ?DateTime(2007-12-13T12:07:15Z)

Policy suggestion #1

-- SalokineTerata ?DateTime(2007-12-13T21:04:21Z)

1. Each Portal have its Category alias.

   • Example: Software have CategorySoftware

2. These Categories are just a redirection to corresponding Portals

   • Example: CategorySoftware contain #reditect Software

3. In Article, you can insert reference to portals using Category

Breadcrumbs

-- FranklinPiat ?DateTime(2007-11-23T09:09:56Z) : The new Moinmoin engine DebianWiki is now running create breadcrumbs automatically at the top of the pages.

I assume we should remove them from the page content.

=== Policy suggestion #1 ==== If a page belong to a collection, but isn't a ?/SubPage of it's parent :

1. consider renaming the page as a subpage (if it really belongs to it).
2. add a link the "parent" page in the see also (if it doesn't only belongs to it).

?Anchor(discussionspages)

URL for Discussion page convention

Same as above: there is a lack of consistency. Some discussion pages like this one are named using the camel case (?DebianWikiConventionsDiscussion). Other pages use a slash (.../Discussion), like ["FrontPage/Discussion"]. Which standard to use? -- AugustinMa ?DateTime(2007-10-08T10:01:05Z)

Something lile [:/Discussion:Discussion] is easy to use with templates or when you copy and paste contents. Relative path are more flexible. I recommend to integrate this link in the default banner to invite readers for discussion.

• Example: [:/Discussion:Discussion]

1. Since it's very sensitive to edit a user's comment(s) in a Discussion (["ReFactor"]), we don't want to have lots of unneeded ones. 2.We don't want to turn wiki.d.o into a mailing list ;) 3. Including Discussion at the top right of the page requires to use table for the header, which make it complex (less easy to read). -- FranklinPiat ?DateTime(2007-10-14T23:49:02Z)

Policy suggestion #1

-- SalokineTerata ?DateTime(2007-10-11T21:08:49Z)

• Each banner include a discussion link like:

  [:/Discussion:Discussion]

 (!) [:/Discussion:Discussion]

Policy suggestion #2

proposition #2 withdrawn. see Policy 3

Policy suggestion #3

• Each banner could include a discussion link like:

  [:/Discussion:Discussion]

 (!) [:/Discussion:Discussion]

• This Discussion link is optionnal. Use it only when needed.

• See DefaultTemplate if necessary

?Anchor(banner)

Banner

Articles don't have real imposition in their forms. Just some informations are strongly recommended.

• A knowledge level indicator (see section Knowledge level indicator of article)

• A path named Fil d'Arianne: The path broswed to come on current article. ["FrontPage"] > Portal Welcome ?BR ["FrontPage"] > ["Portal_Welcome"] > A Page ?BR ["FrontPage"] > [:Portal_Welcome:...] > ["A_Page"] > Discussion

  • note: In this example, the name of pages will be:

     "FrontPage"
     "Portal Welcome"
     "A_Page"
     "A_Page/Discussion"

• A link to Discussion. Just the link, the page will be created if needed.

• If this page have some translations, you must indicate them, it's very important. You can, if you are capable, synchronize your version. English version is the swivel page. If someone do an update in a translated page, he must synchronizes it with english version or to notify this update in the english discussion page.

I don't really like ".." because i dont't where i would end up if i click it. I assume that if the lines because too long, it's because the path from the top is too long. -- FranklinPiat ?DateTime(2007-10-10T23:53:24Z)

Supplementary recommendations about portals

Portal ["Portal_Introduction"] play a part of template. Use it to create a new portal easily.

Besides preceding recommendations, portal pages must be named like:Portal + _ + Title of portal.

• Example, the french portal talking about hardware is named Portail_Materiel

• Example, the english portal related to softwares is named Portal_Software

They must contain:

• The same banner like using on ["Portal_Introduction"]
• A short portal description starting an icon which is symbolized it. This icon must be relevant and to assert perfectly the portal.
• A list of links pointing to articles or sub-portals.
• All portals must be attached like a tree.

Supplementary recommendations about articles

• Try to write your article in accessible language for user the less expert. In article tagged Beginner level, this recommendation in obligatory.

• Try to give two method: a GUI version for User level and a CLI version for Advanced User level.

Policy suggestion #1

-- SalokineTerata ?DateTime(2007-10-11T21:08:49Z)

• Portals banners includes:

  • Path like: [:FrontPage:Frontpage] > [:Portal_AThing:A thing] > Current Portal

  • Indicate translation links
  • Insert Discussion link

  • Refer to PortalTemplate to respect the way

• Article banner includes:
  • Try to attach your page to a portal page

  • Path like: [:FrontPage:Frontpage] > [:Portal_AThing:A thing] > Current Page or, if page is not attached to a portal,  [:IndexPage:Index page] > Current page . in this case, Index must be attached to a portal

  • Indicate translation links (very important to search if exist!)

  • Insert Discussion link

  • Refer to DefaultTemplate to respect the way

Footer

Policy suggestion #1

-- SalokineTerata ?DateTime(2007-10-11T21:44:25Z)

• Footer is optinal
• Insert Categories
• Insert a section like "See also" for transversal links.
• Insert tags

• Refer to DefaultTemplate to respect the way

Warning

If you find redundant articles, please, insert this flag at the top of the page:

I Think it isn't important for the visitor, when he/she starts reading the page, to known that the page duplicates the content of another one. So we don't need to put a big colored warning : We could put a simple link at the bottom of the page, so if a user actually don't find the answer, he/she can carry-on on another page. -- FranklinPiat ?DateTime(2007-10-10T23:53:24Z)

• Ready to paste:

{{{||<tablestyle="width:65%;margin-left:35%;padding-left:30pt" style="border:1pt solid #b48;border-left:5pt solid #d4a">Redundant : This article contain redundant information.?BR Please, merge it with ["Name_of_the_other_article"].|| }}}

If you find an article without enough information, please, insert this flag at the top of the page:

• I Think it isn't very important for the visitor, when he/she starts reading the page, is incomplete. it's still a good idea warn him/her. we could simply use  /i\ This article have not enough content.... AND tag the page with FixMe -- FranklinPiat ?DateTime(2007-10-10T23:53:24Z)

• Ready to paste:

{{{||<tablestyle="width:65%;margin-left:35%;padding-left:30pt" style="border:1pt solid #b48;border-left:5pt solid #d4a">Not enough content : This article have not enough content.?BR Please, improve it or merge it in an article having the same goal.|| }}}

Portals are good tools to identify redundant articles. If you find its, finish link with this simley X-(

• Example:

  • [:DebianIntroduction:Introduction of Debian], [:Debian Introduction:Another introduction of Debian]

-- SalokineTerata ?DateTime(2007-10-10T21:57:29Z)

• Another idea of a Warning:

-- SalokineTerata ?DateTime(2007-10-12T22:49:03Z)

• regarding the page redirection : see [:?DebianWiki/WikiPage#rename:DebianWiki/WikiPage#rename] (-- FranklinPiat ?DateTime(2007-10-16T20:16:46Z))

Policy suggestion #1

-- SalokineTerata ?DateTime(2007-10-15T21:23:02Z) (restart 10 days remaining)

• Don't tag at the bottom of the page. Warning tag is for authors, not for readers
• Insert tag on the footer page
• Tag must be less aggressive looking like:

  • {i} [:CategoryRedundant:Redundant pages]: [:ARedundantPage:A redundant page], [:AnotherRedundantPage:Another Redundant Page] 

• Page without enough content can be directly merging or remove

• When you merge a page, sometimes, it's right to keep dead page and convert it as a redirection #redirect MergingPage (Optional for short, obligatory for important article)

Wiki Policy Approbation

• All discussions finish by a resolution. Resolution is a synthesis of discussion, point by point. If no one relaunch discussion after 10 days, resolution is validate.

  Once resolution validate, it move to ["DebianWiki/EditorGuide"]. We can resume Policy creation process by:

• Discussion any where on this Wiki

• Discussion speak about a policy, move it to ?DebianWikiConventionsDiscussion

• Try to create a stable discussion

• Discussion is stable ? try to suggest a resolution ( Policy suggestion) (if not, return to point (3.)

• Resolution is stable since 10 days, move it to ["DebianWiki/EditorGuide"] and move old discussion to "Old discussions" below (if not, return to point 3.)

Management understanding reader level

The Portal Welcome is composed in 4 global parts. Each part aggregate other portals by knowledge level. Language using in article must be adapt to reader level. You can differentiate knowledge level like this:

• Beginner: Someone who don't know any thing about Linux, who don't know what is Debian and can have an overview of what is Windows. Articles must be written in no-technical language. This is a beginner in general concept of informatic.

• User: Someone using only graphic tools. All computing words must be explain for example with a Wikimedia link. Abbreviations are explained too. So, an article characterized User level is basically based on GUI tools (Graphic User Interface)

• Advanced user: Someone who understand effectiveness of a shell or want to use Debian as server. Language must be informatic and contained official links or homepages. So, an article characterized Advanced User level is basically based on CLI tools (Command Line Interface).

• Developer/Contributor: Who want to contribute to Debian project. Language is technical and defined. Reader must know himself how to search more informations. Source code and programming languages are get onto.

?Anchor(pages-names)

URL / page naming convention

• What does it mean ?

  (Don't count this discussion in 10 days remaining, I'm OK with your policy suggestion)

Use of CamelCase

As you, I don't like particulary CamelCasedTitled. I prefer naming conventions [http://en.wikipedia.org/wiki/Help:Page_name like Wikipedia]. -- SalokineTerata ?DateTime(2007-10-10T21:57:29Z)

Currently, out of 5000 pages, 200 pages contains an underscore, 3800 are ?CamelCased. In order to remain consistent, we probably want to stick to moinmoin's (ugly) convention.

-- FranklinPiat ?DateTime(2007-10-14T23:49:02Z)

Felipe Augusto van de Wiel (faw) - Monday 22 October 2007 05:59:55

• I would use a more strict wording in the policy, specially with regards

  • to use or not CamelCase or to use or not underlines, if the idea is to be consistent, we should clearly *not* recommend something, like, use CamelCase and avoid "_".

Policy suggestion #1

• For Portals, it's different. It must differentiate than articles. I prefer a strict convention clear and condensed with underscore or ":".?BR

• Example of Portal naming for "Portal of how to install and configure your Webcam":

  • Example #1: ["Portal_Webcam"]

  • Example #2 (why not [http://en.wikipedia.org/wiki/Portal:List_of_portals like Wikipedia] ? but not very compatible with Moinmoin): ["Portal:Webcam"]

  • Counter-example #1: PortalWebcam

  • Counter-example #2: PortalHowToWebcam

  • Counter-example #3: Portal_HowTo_Webcam

  • For link, I recommend some thing like: [:Portal_Webcam:Webcams]

-- SalokineTerata ?DateTime(2007-10-15T21:23:02Z)

• What do you think if we use only CamelCase with "Portal" prefixe ? In your example, You show me an issue in my suggest. Take this french example: Portail_Wiki.

• In english: Portal_Wiki
• In german: Portal_Wiki too ! So you propose finished by country name. good choice. Can we go further ? take exactly the same idea of Page Naming and just add "Portal" prefixe for all language ? Take same example:

• In english: ?PortalWiki

• In german:?PortalWikiGerman

• In french: ?PortalWikiFrench What do you think about this ?

-- SalokineTerata ?DateTime(2007-10-16T21:27:49Z)

• I think it's important to differentiate portal page naming than article page naming. It's easy to see structural pages, because all pages start with a prefixe. If we don't use something to differentiate them, I fear that's maintening routine will be more difficult.

  If you don't want to use a prefix, another idea, We can use a category like CategoryPortal or ?CategoryIndex ?

Felipe Augusto van de Wiel (faw) - Monday 22 October 2007 05:59:55

• I would use a more strict wording in the policy, specially with regards

  • to use or not CamelCase or to use or not underlines, if the idea is to be consistent, we should clearly *not* recommend something, like, use CamelCase and avoid "_".

Policy suggestion #1

• Using separated words with underscore

• Translated portal have a translated title Portal_Hardware / Portail_Materiel 

• When translated page is modified, synchronize english version (if you can't, notify discussion english page)

Policy suggestion #2

• No, this rule is about the writing style and subject include in portal. We can forget level notion. Sure, articles attached in beginner portals need more knowledge than administrator portals, but the real goal is to create kind of "domain" or Workspace to consolidate the same thing like these:
• Good examples:

  • [http://www.mediawiki.org/wiki/MediaWiki/fr mediawiki] sections are very clear

  • [http://docs.fedoraproject.org/ fedora] only 3 sections, but in the same direction that I propose

  • [http://wiki.mandriva.com/fr/Accueil Mandriva] look at the bottom of the page. Very good approach like I want to explain ! (only 3 sections, but in the same direction too)

  • [http://wiki.netbsd.se/Main_Page NetBSD] another approach not exactly in the same idea, but simple and effective.

• Bad examples:

  • [http://susewiki.org/index.php?title=Main_Page Suse] not clear, too long page

  • [http://www.mepis.org/docs/en/index.php/Main_Page Mepis] not very bad, but too simple and section delimitation are confused

  • [http://doc.ubuntu-fr.org/ ubuntu (FR)] very too long

  • [http://slackwiki.org/Main_Page Slackware] no comment ...

  • [http://gentoo-wiki.com/Main_Page gentoo] too complex index, but good.

  I have see many others but not significant

  Just for the fun: look the banner navigator on [http://www.apple.com/mac/ Apple site]. I like this ! ... but it's utopian ...

IMHO, I am quite happy with the categories on the FrontPage (using debian + developping debian + news). A Debian Quick-Start section would be on my wishlist (Beginner might be misleading).

-- SalokineTerata ?DateTime(2007-10-16T22:07:53Z)

• Yes, it's true. I'll try to propose to merge frontpage categories to : News, User, Admin, Developer, Wiki. where Beginner go to User domain. Quick-Start could be connect to Wiki

Felipe Augusto van de Wiel - Monday 22 October 2007 05:59:55

• I like the ?PortalProposal but I think it has a better chance to get adopted if you really map the current FrontPage to the Proposal, or is it your intention to drop all the links?

-- SalokineTerata ?DateTime(2007-10-23T21:24:17Z)

• Yes, the goal is to keep all existing links on current FrontPage. These links will are move in the appropriate portal.

Policy suggestion #1

• Beginner

• User

• Advanced user

• Developer/Contributor

Ready to paste:

 {o} {o} {o} ''Beginner''
 {*} {o} {o} ''User''
 {*} {*} {o} ''Advanced user''
 {*} {*} {*} ''Developer/Contributor''

Each parts of portals must be guide the readers. By example, Portal_Shells is classified Advanced user, but at first, this portal must explain what is a shell and the basic howto. Next, real howto can be presented. Other example, Portal_Developer (classified Developer/Contributor) must present official references, debian.mentors, your first package howto ...etc and all of what you want when you would like to become a new developer.

Maybe we can rename this four levels as Beginner, User, Administrator and Developer ? -- SalokineTerata ?DateTime(2007-10-10T21:57:29Z)

Franklin

• Comment regarding main portal is composed of four domains : I think the pages (and portals) should be organised according to what the visitor search, not what he/she knows. i.e. Does a visitor in "level 3" have to visit all 3 levels to find what he/she wants ?

Felipe Augusto van de Wiel - Monday 22 October 2007 05:59:55

• For knowledge indicator, just drop the "non star" version, use only three levels with at least one star.

?Anchor(links)

Links pointing to articles

• Example: [:DebFrWifi:Installation and configuration of Wifi card] (in french)

alternative :

• Example: [fr] [:DebFrWifi:Installation and configuration of Wifi card]

An helpful description, understandable and concise.

• Example: Don't refer to X System when it's not needed

• Exemple: Not Debian word anywhere. We know that we will talk about Debian on this Wiki. We are not going to speak about Redhat.

-- SalokineTerata ?DateTime(2007-10-15T21:23:02Z)

• What do you think about articles wrotten in non-native language ?

  • What to you mean ? (-- FranklinPiat ?DateTime(2007-10-16T20:16:46Z))

    • -- SalokineTerata ?DateTime(2007-10-16T22:07:53Z) You have removed Not native language links finish with destination language (look at suggest #1)

Policy suggestion #1

• Assuming that if a page is properly named (as it should be), the "link title" = "page name"

• If a link is within a paragraph, it can be reformated [:PageName:page name] (i.e lower cased, space separated, and shorten if the context is clear).

• A link that is not in a pagraph (list of "see also"...), then it should be left intact ["PageName"].

• Links pointing to another language finish with ''(in language)''

  • Example:

    • [:FR/QuequeChose:SomethingInFrench] (in french)

Is it the official portal of Wiki Debian ?

This set of page comes from user's initiative as you. Portals can be considered as official because there are on Debian Wiki. On other hand, the official page assembled information of the Wiki is the ["FrontPage"]. In brief, it's not the most important question. The real question is: Is this portal answer to my needs ? If you reply No ... you can contribute to improve it. If you reply Yes, speak well of it.

Portal concept must be more stable, more hold and more translated. Next, maybe we can update the frontpages ?

Policy suggestion #1

• note: the FrontPage is an exception. DebianWiki content use the describe scheme. -- FranklinPiat ?DateTime(2007-10-14T23:49:02Z)

  I find it a bit messy to combine all the languages in one wiki. The ideal would be to have one sub-site for each language, either something like en.wiki.debian.org/ or wiki.debian.org/en/. But this would require more work from the [?DebianWikiAdministrators administrators] to keep the system up to date, etc. I don't know what the second best solution would be, but it's worth discussing. Maybe we could have the language tag (Fr, De...) as part of the page name like this: ?FrSomePageInFrench, ?DeSomePageInGerman, etc. -- AugustinMa ?DateTime(2007-10-09T04:05:04Z)

  • en.wiki.debian.org would be nice but we can't : Each (language-)site would be a separate instance of moinmoin (Separate user accounts ; "Internal" links wouldn't work, etc). -- FranklinPiat ?DateTime(2007-10-14T23:49:02Z)

  I prefer to finish the name by the translating language. It's easy to find translating pages like:

• ["Debian"]

• ["DebianFrench"]

• ["DebianGerman"]

• ["DebianRussian"] When using the FindPage, all translations are grouped. -- SalokineTerata ?DateTime(2007-10-10T21:57:29Z)

  • That's what's currently in use (mostly), let's stick to it. -- FranklinPiat ?DateTime(2007-10-14T23:49:02Z)

  Like [:?DebianWikiConventionsDiscussion#links:here], can we change in

   Linking
   
   Linking to the same page, in other language, see Page header below. 
   Links to non translated page should be prefixed by [en].

  to: Links to non translated page should be follow by: (in destination language)

  ?BRExample:

• [:DebianReleases:Les versions de Debian] (en anglais)

• [:DebFrAmiloM:Some improvements for Fujitsu-Siemens laptop] (in french)

  Bye.?BR -- SalokineTerata ?DateTime(2007-10-12T19:23:10Z)

Felipe Augusto van de Wiel - Monday 22 October 2007 05:59:55

• The translation should use the subdirectories approach, similar to PortugueseBR, it makes it easier to build consistency (same page names) and allow easier integration with some sort of tool in the future like po4a.

-- SalokineTerata ?DateTime(2007-10-24T18:42:15Z)

• So there are currently 2 main suggestions:

  Suffixed method: "?PageName" + "Language" like ?DebianIntroductionFrench Prefixed method: "Language" + "/" + "?PageName" like PortugueseBR/DebianIntroduction I don't know what's the best way. You suggest that "Prefixed method" is the best for using with PO. Why ?

Felipe Augusto van de Wiel

• Because it is the natural way considering all other translations, we use it in Debian Women Wiki, we use it in CVS webwml, D-I Manual, Debian Doc CVS, there is always subdirectories with the other languages.

-- SalokineTerata ?DateTime(2007-10-24T18:42:15Z)

• Could you give us Internet ressources where I can find arguments about this ?

Felipe Augusto van de Wiel

• Sorry, I can't. That's my argument based on my experience with i18n/l10n. I can tell you that it is more consistent with the Name

  Space, because it doesn't polute it, FrontPage will always be FrontPage, doesn't matter the language, probably, build statistics and l10n tools on top of this models would be easier, considering po4a and this model.

  IMHO the <?PageName><Language> was a natural extension of the wiki model and an inheritance from wikis that doesn't support URLs that looks like folders. There is another point that need to be considered that is

  related with the Content Negotiation, MoinMoin supports it in some way and it probably needs to be considered while defining the recommended procedure for Debian Wiki.

RaphaelHertzog Wednesday 24 October 2007 21:11:12

• Original message: Du point de vue de quelqu'un qui est abonné à de nombreuses pages du wiki grâce à des abonnements génériques comme "Teams/*" ou "Alioth*", je confirme qu'utiliser la langue en préfixe c'est mieux parce qu'en suffixe, cela veut dire que je recevrai les notifications sur les mises à jour des traductions, ce que je ne souhaite pas (sauf abonnement explicite à Fr/Teams/* ou ?FrTeams par exemple). For someone who take out lot of subscriptions of this Wiki using generic subscription like "Teams/*" or "Alioth*", I confirm using prefixed method is better than suffixed. In suffixed mode, I would received all translation pages (I don't want this except explicit subscription).

Policy suggestion #1

• All pages are named in english

• This page is called Referent Page. When you modify a translated page, you must update or notify the referent page

• Translated page is named like "Language" + "/"+ "?NameOfReferentPage"

  • Example:

    • Referent page: ?SomeThing

    • French page: French/Something

• (optionnal) To help user that doesn't speak english, you can create a linker page named "Initial of language" + "/" + "?PageInNativeLanguage". This page redirect to the translated page with the content #redirect "Language" + "/"+ "NameOfReferentPage"

  • Example:
    • Linker page: FR/QuelqueChose

    • Content of the linker: #redirect French/Something

    • Translated page: French/Something