Re: Debian Wiki: renaming pages
On 21 Feb., 23:32, Frank Lin PIAT <fp...@klabs.be> wrote:
> On Sat, 2009-02-21 at 15:27 -0600, Lukasz Szybalski wrote:
> > On Sat, Feb 21, 2009 at 1:42 PM, Frank Lin PIAT <fp...@klabs.be> wrote:
>
> > > On Sat, 2009-02-21 at 18:56 +0100, rupert THURNER wrote:
> > >> On Sun, Feb 15, 2009 at 23:41, Frank Lin PIAT <fp...@klabs.be> wrote:
>
> > >> > Please don't use the "Include" feature for list of languages (like
> > >> > EeePC/Langs).
>
> > >> or takehttp://wiki.debian.org/fr/Manual-Howtowhere one transaltion
> > >> is called "polski", pointing to a link "francais".
>
> > You've deleted :,[:pl/Manual-Howto:Polski] and added
> > [:Français/Manual-Howto:Polski].
>
> > I've reverted your change right now, so we are good on that page.
>
> Thank you.
> (But actually, the page doesn't exists, so we should drop the link!)
>
> > > Linking among translated pages is really the smallest issue we have.
> > > Some of our needs are:
> > > 1. Migrate important (static) pages to thewww.d.o, then translate them.
> > > 2. Use an efficient tools that allow translators to track what was
> > > changed and what translation needs to be updated (which page, which
> > > paragraph => What was the previous text, whats the new text, what
> > > was the old translation.. see poedit)
> > > 3. Implement a mean to automatically disable a translation if it is
> > > lagging too much.
> > > 4. Proper (i.e automatic) content negotiation, so the best alternatives
> > > is presented to the user.
> > > (which would probably solve the linking issue)
>
> > > Since many (most?) pages are translated in very few languages, I would
> > > rather maintain links manually, rather that having one more transition
> > > to manage... while migrating to a new moin version (And trying to solve
> > > the issue properly at the same time).
>
> > > Also, the [[Include()]] macros adds complexity to the wiki pages, which
> > > makes it less accessible to contributors.
>
> > I on the other hand believe that using include allows me to create a
> > page that has more relevant content then providing links to 30 other
> > pages.
> > I could create a page for sys admins and include various pages and
> > create one place to get all the information, just like Debian
> > reference did. I could pull individual "ftp server", "ssh
> > server"..etc.. Who ever would be looking for one big sys admin
> > instructions could print this page. If you say that include should not
> > be used then that person would have to print each section on its own.
>
> I don't say that [Include()] shouldn't ever used, (I actually pushed to
> use it in xx/WiFi pages. We might use it in the FrontPageV3).
> However, in this situation, let's wait for moinmoin 1.8 and FrontPageV3
> to know what we can do about translation.
> Lucasz, You mean that you want to aggregate multiple pages into a single
> [PDF] PDF file for offline viewing/printing, ok.
> It doesn't means that there needs to be a actual wiki page with that
> content (exporting selected pages to docbook, then merge them)
>
> > I think the include feature is great and allows one person to provide
> > better documentation, while allows each piece to be maintained by
> > someone else. Include show be allowed and recommended on some pages.
>
> The wiki already has a structure. If that structure is wrong, let's find
> out why, then fix it.
> BTW, I think that the only part which is wrong is the frontpage: It
> leads visitors to believe that they would find on this wiki some
> documentation that isn't and shouldn't be on the wiki.
i agree with lukasz. include is great to break up contents. and also
in its main purpose: to have contents once and reuse it multiple
times.
90% of all language bars are wrong, not pointing to the correct pages
or not all of them. every language bar is the same for the same page,
and therefor reused 5-15 times. debian is known for high quality. in
software and contents.
may i invite you, franklin, to pls fix all the translation bars? there
is only 150 of them, hehe. and when you are tired you tell us :)
kind regards,
rupert.
Reply to: