Testing MDC
Sheppy
with.
A few things to note before I provide the URL:
- CHANGES MADE ON THE TEST SERVER WILL NOT BE PORTED TO THE REAL
DATABASE.
- The database installed on the test server is several weeks old.
- The help and certain other content, particularly in the MDC:
hierarchy, has not been updated yet to reflect the switch from
MediaWiki to MindTouch Deki.
- CHANGES MADE ON THE TEST SERVER WILL NOT BE PORTED TO THE REAL
DATABASE.
- We don't yet have the localized skins in place, so if your language
isn't English, you'll see little bits of English here and there.
- CHANGES MADE ON THE TEST SERVER WILL NOT BE PORTED TO THE REAL
DATABASE.
- This is not installed on the final hardware, which will be somewhat
higher capacity.
I'd appreciate it if folks would thump on it for a while. Try doing
some edits, browse around, search, and so forth.
I'll be on vacation for the next week but will be peeking at my email
to see if there are any crises, and will provide assistance where I
can if people get confused by the new system. I'll be updating the
help and so forth soon. Might touch it a bit while I'm on vacation,
but I hope I can make myself wait until I get home. :)
The URL is: http://devmo.dekiwiki.mozilla.org/
Eric Shepherd
Developer Documentation Lead
Mozilla Corporation
http://www.bitstampede.com/
Benoit Leseul
I can't seem to log in to the test site. There seems to be a problem
with my account migration or the login page. My account name is
'BenoitL'.
The log in page says: You put in a bad username or password.
I tried the password recovery link, but didn't get any e-mail. My
password is correct anyway since I just tried it on the regular MDC.
I also tried to create a new account with the same name, but it
doesn't work (the account already exists).
Creating an entirely different new account worked though.
Thanks for your help!
--
Benoit
On Tue, Jul 1, 2008 at 3:46 AM, Sheppy <the.s...@gmail.com> wrote:
> We now have the new version of MDC up and ready for experimenting
> with.
> [...]
> The URL is: http://devmo.dekiwiki.mozilla.org/
>
> Eric Shepherd
> Developer Documentation Lead
> Mozilla Corporation
> http://www.bitstampede.com/
> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
>
Mook
> We now have the new version of MDC up and ready for experimenting
> with.
>
more clearly :)
http://devmo.dekiwiki.mozilla.org/En/NsIObserverService
"It is scriptable and has been frozen since . " that's missing a
version number. I think that template in general is a little broken?
#addObserver.28.29
Whitespace import is whacked; the indenting seems too wide. Doubled?
http://devmo.dekiwiki.mozilla.org/Special:Search?search=concat
The first result says concat, but no sign of what namespace/context.
That kinda sucks ;)
http://devmo.dekiwiki.mozilla.org/en/XUL/Attribute/class
There's no obvious way to figure out what links here (i.e. what sorts of
things attributes/properties apply to). (Yes, that's useful on the
mediawiki)
http://devmo.dekiwiki.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/String#String_instances
=== and ==== (subheadings) seem to be not converted at times.
The tags at the bottom look broken. (Nothing tagged as XUL_Attributes?)
No editing / logging in if you don't have JS. This is more of an annoyance.
Excited to see where this leads :)
--
Mook
Nickolay Ponomarev
<mook.moz+nntp.n...@gmail.com> wrote:
> http://devmo.dekiwiki.mozilla.org/En/NsIObserverService
I don't suppose the URLs could be easily fixed?
(/en/nsIObserverService). The wiki seems to be case-insensitive, and
the first letter is automatically upper-cased in the links. Not a big
deal certainly.
Nickolay
Nickolay Ponomarev
> We now have the new version of MDC up and ready for experimenting
> with.
>
I have several questions/comments:
1) there are no links to the edit diffs from recent changes, are
there? How should the changes to the wiki be controlled/reviewed?
2) in the edit mode, is there a "preview" button I can use to see
markup like [[en/Another page]] rendered?
3) is it just me or the "No transformation" dropdown and the dialog
opened with the "insert link" button don't work (rv:1.9.0.1pre
Gecko/2008062606)?
4) there's a problem with the rich editor - you can't edit a page in
an external editor, since the markup gets messed up when copy-pasting,
- and it doesn't seem the edits in the rich editor can be auto-saved.
Deki doesn't have this functionality and session restore doesn't work,
since the edit page is using ajax.
5) Putting locale info into the page name (all english pages have the
"en/" prefix) prevents me from typing [[nsIDirectoryService]] to link
to the nsDirectoryService page. Is there another way to do "accidental
links"?
Nickolay
Sheppy
> Hi Eric,
>
> I can't seem to log in to the test site. There seems to be a problem
> with my account migration or the login page. My account name is
> 'BenoitL'.
>
> The log in page says: You put in a bad username or password.
> I tried the password recovery link, but didn't get any e-mail. My
> password is correct anyway since I just tried it on the regular MDC.
> I also tried to create a new account with the same name, but it
> doesn't work (the account already exists).
> Creating an entirely different new account worked though.
Oh, I probably should have mentioned that -- all passwords on the
current test machine were reset to be empty, since MindTouch did the
conversion for us and was not under NDA, we didn't want to chance
exposing anyone's passwords. In addition, all email addresses were
emptied out too, for the same reason. Just log in using an empty
password and change it using the preferences for now. The real
passwords and email addresses will be migrated over once we go live
for real.
Sheppy
> On Tue, Jul 1, 2008 at 11:57 AM, Mook
>
> >http://devmo.dekiwiki.mozilla.org/En/NsIObserverService
>
> I don't suppose the URLs could be easily fixed?
> (/en/nsIObserverService). The wiki seems to be case-insensitive, and
> the first letter is automatically upper-cased in the links. Not a big
> deal certainly.
We have a ticket filed with MindTouch regarding this issue.
Sheppy
> On Tue, Jul 1, 2008 at 5:46 AM, Sheppy <the.she...@gmail.com> wrote:
> > We now have the new version of MDC up and ready for experimenting
> > with.
>
> > The URL is:http://devmo.dekiwiki.mozilla.org/
>
> I have several questions/comments:
> 1) there are no links to the edit diffs from recent changes, are
> there? How should the changes to the wiki be controlled/reviewed?
We have a ticket filed with MindTouch to get this feature added. I
hope to see it coming very soon.
> 2) in the edit mode, is there a "preview" button I can use to see
> markup like [[en/Another page]] rendered?
No, there isn't currently one. That's something that I should
probably ask them about.
> 3) is it just me or the "No transformation" dropdown and the dialog
> opened with the "insert link" button don't work (rv:1.9.0.1pre
> Gecko/2008062606)?
Transformation menu: It's not just you.
Insert link: I haven't had that problem. I'm running Firefox 3
release here.
> 4) there's a problem with the rich editor - you can't edit a page in
> an external editor, since the markup gets messed up when copy-pasting,
> - and it doesn't seem the edits in the rich editor can be auto-saved.
> Deki doesn't have this functionality and session restore doesn't work,
> since the edit page is using ajax.
Which markup are you referring to? Are you copying the XHTML source
or the rich version of the content?
I'll ask MindTouch about the possibility of adding auto-save.
> 5) Putting locale info into the page name (all english pages have the
> "en/" prefix) prevents me from typing [[nsIDirectoryService]] to link
> to the nsDirectoryService page. Is there another way to do "accidental
> links"?
[[nsIDirectoryService]] should work. If it doesn't, that's a bug.
I'll let MindTouch know.
Sheppy
wrote:
> Sheppy wrote:
> > We now have the new version of MDC up and ready for experimenting
> > with.
>
> Ah, so this is where bug reports go? The blog post could mention this
> more clearly :)
>
> http://devmo.dekiwiki.mozilla.org/En/NsIObserverService
> "It is scriptable and has been frozen since . " that's missing a
> version number. I think that template in general is a little broken?
Looks like it. I've put it on the list.
> #addObserver.28.29
> Whitespace import is whacked; the indenting seems too wide. Doubled?
I don't see anything wrong here. What looks too wide?
> http://devmo.dekiwiki.mozilla.org/Special:Search?search=concat
> The first result says concat, but no sign of what namespace/context.
> That kinda sucks ;)
Well, not sure what namespace or context you want. It's an article
called "concat" :)
> http://devmo.dekiwiki.mozilla.org/en/XUL/Attribute/class
> There's no obvious way to figure out what links here (i.e. what sorts of
> things attributes/properties apply to). (Yes, that's useful on the
> mediawiki)
Click on "More Options" then "Pages that link here".
> http://devmo.dekiwiki.mozilla.org/en/Core_JavaScript_1.5_Reference/Gl...
> === and ==== (subheadings) seem to be not converted at times.
Looks like importing articles from other pages into the content of
another article isn't dealing with those headings correctly. I'll ask
MindTouch to look into it.
> The tags at the bottom look broken. (Nothing tagged as XUL_Attributes?)
Yeah, that's reported to them already.
Nickolay Ponomarev
>> I have several questions/comments:
>> 1) there are no links to the edit diffs from recent changes, are
>> there? How should the changes to the wiki be controlled/reviewed?
>
> We have a ticket filed with MindTouch to get this feature added. I
> hope to see it coming very soon.
>
of my problems were known, but didn't see them logged anywhere.
>> 3) is it just me or the "No transformation" dropdown and the dialog
>> opened with the "insert link" button don't work (rv:1.9.0.1pre
>> Gecko/2008062606)?
>
> Transformation menu: It's not just you.
>
> Insert link: I haven't had that problem. I'm running Firefox 3
> release here.
>
Thanks. I guess I'll try later then.
> Which markup are you referring to? Are you copying the XHTML source
> or the rich version of the content?
>
The rich version. Copy-pasting to MS Word and then right back changes
the formatting of the wiki page and puts some MS junk markup there.
XHTML source is quite hard to edit, but it's probably what I'll end up
doing for non-trivial edits.
> I'll ask MindTouch about the possibility of adding auto-save.
>
That would be great.
>> 5) Putting locale info into the page name (all english pages have the
>> "en/" prefix) prevents me from typing [[nsIDirectoryService]] to link
>> to the nsDirectoryService page. Is there another way to do "accidental
>> links"?
>
> [[nsIDirectoryService]] should work. If it doesn't, that's a bug.
> I'll let MindTouch know.
>
[[en/nsDirectoryService]] of course works.
Thanks for your reply. Looking forward to the migration.
Nickolay
Sheppy
the MindTouch bug database at http://bugs.developer.mindtouch.com/
I believe you can see a list of bugs I've filed here:
Note that some bugs aren't filed into their system because I've had
trouble logging into the bug system for the last few days.
John J. Barton
> We now have the new version of MDC up and ready for experimenting
> with.
The text is hard to read because its contrast is too low. The
information is hard to gather because there is too much whitespace.
Some blue text without underlines are links. Some blue text is
underlined. Some blue text is not a link. Some text is purple and seems
to mean "this is a link but ha ha, there is no information on the linked
page". This inconsistency is perplexing, but the biggest real problem is
the links that don't link. Please don't link to dead pages.
Scroll down on the page
http://devmo.dekiwiki.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/String
until the entry for "big" is at the top of the browser. Sit back and
take a look. "This space intentionally left blank"? I don't think this
kind of documentation is helpful. If you don't have something to say,
don't say it.
Scroll to the top of the page
http://devmo.dekiwiki.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/String
If you have a large monitor you can see the first few lines of
Description. This first page is the most important view for doc users.
It has relatively little information and what is there is confusing even
given the trivial nature of the topic. Literals should be first, should
used in the constructor examples and the parameters should be described
immediately after the function call. In fact why is there a heading
"Syntax" and "Parameters" at all? The page is about String objects. They
have constructors which have syntax, but they don't have syntax.
ok I better stop.
John.
Sheppy
converted the database for us and was not at the time under NDA), we
set all user accounts' passwords to be empty on the test server, and
set all email addresses to something like "f...@bar.com". Just log in
using no password, then you can change your password and email address
using the preferences if you wish.
The correct user information will be imported when we do the final
conversion of data from the current MDC to the new one. MindTouch is
under NDA now, so your information will be protected.
John J. Barton
> We now have the new version of MDC up and ready for experimenting
> with.
I edited
http://devmo.dekiwiki.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_Objects/String
and the editor seems decent. Slow but that is partly because it has a
bunch of errors like
Error in parsing value for property 'filter'. Declaration dropped.;
that slow it down.
At the bottom of the edit buffer is a bunch of markup like:
{{template.JSInherits("Function", "Properties", "caller", "constructor",
"length", "name")}}
Its a bit bizarre to have a WYSIWYG editor for some parts of the page
and not for other parts. Can these be separately edited? That is, when
you edit a section they don't appear, they only appear when you edit
them explicitly?
The pages use the term "instance" and the term "object". Pick one.
Personally I vote not to use the word "instance" at all because it is
widely used as "instance of a class" which is not true in Javascript.
John.
Mook
> On Jul 1, 3:57 am, Mook <mook.moz+nntp.news.mozilla....@gmail.com>
> wrote:
>> #addObserver.28.29
>> Whitespace import is whacked; the indenting seems too wide. Doubled?
>
> I don't see anything wrong here. What looks too wide?
wide space, for some odd reason. Will be keeping track of this
separately from MDC (since that's probably a local problem).
>> http://devmo.dekiwiki.mozilla.org/Special:Search?search=concat
>> The first result says concat, but no sign of what namespace/context.
>> That kinda sucks ;)
>
> Well, not sure what namespace or context you want. It's an article
> called "concat" :)
Well, the old Nutch search would say things like "Core JavaScript 1.5
Reference:Global Objects:Array:concat - MDC" instead. So I can tell
what sort of area I'm looking in (JS String? JS Array? XSLT?).
>> http://devmo.dekiwiki.mozilla.org/en/XUL/Attribute/class
>> There's no obvious way to figure out what links here (i.e. what sorts of
>> things attributes/properties apply to). (Yes, that's useful on the
>> mediawiki)
>
> Click on "More Options" then "Pages that link here".
Umm, what More Options? I see
http://img381.imageshack.us/img381/3775/tempey6.png It's not under Site
Tools, nor Languages.
Thanks for looking :)
--
Mook
Mook
> 1) there are no links to the edit diffs from recent changes, are
> there? How should the changes to the wiki be controlled/reviewed?
Oh, yeah, the feature I miss the most (in a separate dekiwiki install,
since I can't seem to login to the devmo test one) is the ability to do
a preview of the diff ("show changes" in mediawiki) before you commit.
With the fancy rich text stuff, that's lacking.
XHTML is also more verbose, harder to read, and doesn't actually
round-trip correctly (deki seems to strip some formatting for me), when
compared with mediawiki markup. Meh, I'll live though.
--
Mook
potappo
In JavaScript, String is the String object, not the character object.
JavaScript has not character object, but Java has it.
I think "String: Javascript's character objects" make confusion.
So, I renamed "Core JavaScript 1.5 Reference:Global Objects:String" as
real site.
I think "Core JavaScript 1.5 Reference:Global Objects" needs to make
this page's section clear.
(section example: Guide, Reference...)
By the way, how can users manually write "Edit summary"?
I can't find a "Edit summary" box....
> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
>
--
potappo
MDC Japanese Translation Leader
mail:pot...@gmail.com
blog:http://d.hatena.ne.jp/potappo/
potappo
I renamed to "String" again.
On Wed, Jul 2, 2008 at 1:34 AM, potappo <pot...@gmail.com> wrote:
> "String: Javascript's character objects" ?
> In JavaScript, String is the String object, not the character object.
> JavaScript has not character object, but Java has it.
> I think "String: Javascript's character objects" make confusion.
> So, I renamed "Core JavaScript 1.5 Reference:Global Objects:String" as
> real site.
> I think "Core JavaScript 1.5 Reference:Global Objects" needs to make
> this page's section clear.
> (section example: Guide, Reference...)
>
> By the way, how can users manually write "Edit summary"?
> I can't find a "Edit summary" box....
>
> On Wed, Jul 2, 2008 at 12:48 AM, Mook
> <mook.moz+nntp.n...@gmail.com> wrote:
Benoit Leseul
First, about the theme. I find it nice, probably even more readable than
the previous one, and easier on the eye. But what I don't like as an
editor are the drop-downs for languages, options and site tools. I think
they should be made more accessible when logged in, or maybe we need
separate user themes like we have in MediaWiki.
I can't find the 'Follow linked changes' tool, even under "More
options". This is a very important tool for localizers to track changes
directly linked from the Main page or the "Firefox N for developers".
Even more so, since I expect the bots will stop making reports like
http://mdc.mozilla.gr.jp/bot/relst/fx3docs.cgi for a while (until they
are updated to work with DekiWiki).
I think the Users pages is mostly useless. You have to type the exact
user name of someone in the search box to find it and there is no means
to browse the list than 50 names at a time, when there are thousands of
them. Even if you happen to type the right name in the search box, you
end up on the User page, where there is actually no link to this user's
contributions.
I find the Popular pages link very nice, since you can now compare the
popularity of all articles in all languages at once. But a language
filter would still be useful in some cases.
When editing a page, I miss previewing my changes, viewing a diff of my
changes, and a backlink to the unedited page (if I want to check how it
was before editing by opening it in a new tab).
Also, most of the top drop-downs are unusable and unrelated to the
existing text (fonts, sizes, styles, ...)
When following a redirection, we get a link to the Redirect page (which
is great), but not to the actual page. If I want to send a link to
someone and I came to the article by a redirection, I can only link to
the redirection :-/
Example: http://devmo.dekiwiki.mozilla.org/en/Online%2f%2fOffline_Events
The old skin has an "Article" link in the header to do this, but you
could simply use the title as a link to the current article (like on
most blogs), or the last part of the breadcrumbs line.
Also related to redirections, the "What links here" tool don't seem to
show redirections. See for example
http://devmo.dekiwiki.mozilla.org/en/Firefox_2_for_developers which has
only three direct incoming links, but dozens with the [[Firefox 2]]
redirect which are not shown in the special page.
I don't like the new diffs at all. They should (at least optionnaly) be
made contextual, I don't want to go trough the whole page to find a two
words change.
Worse, they are shown inline instead of the two versions side by side,
which mades it very difficult to understand the meaning of what was
changed, and almost impossible to cut and paste the new version as a
base for translation.
See
http://devmo.dekiwiki.mozilla.org/index.php?title=En%2FOnline_and_offline_events&diff=0&revision=10
for an example of an unreadable diff on a sentence where the only common
words are "the", "this" and "in". And it is not, by far, the worst
example of that.
And finally, there are several conversion errors on
http://devmo.dekiwiki.mozilla.org/en/XUL/button (and other pages from
the XUL reference), like this:
line 1, column 55: ")" expected
Sorry if most of my comments sound negative, I mostly focused on what I
perceived as regressions. That doesn't mean that there are no useful new
features, but I don't understand why some were actually removed in the
process (I found out in the source that many parts of Deki are actually
based on MediaWiki itself).
--
Benoit
FrenchMozilla l10n team
John J. Barton
> "String: Javascript's character objects" ?
> In JavaScript, String is the String object, not the character object.
> JavaScript has not character object, but Java has it.
> I think "String: Javascript's character objects" make confusion.
> So, I renamed "Core JavaScript 1.5 Reference:Global Objects:String" as
> real site.
> I think "Core JavaScript 1.5 Reference:Global Objects" needs to make
> this page's section clear.
I think this is 'bug'. I changed the page from what ever it said before
to "String: Javascript's character objects" (ok not a great title), but
it had the unintended (by me) effect of moving the page around on the
site I guess. I don't think this is good: in attempting to improve
information we have effect beyond presentation.
Could the first part of the title be read only or at least not edited
with the rest?
John.
John J. Barton
> We now have the new version of MDC up and ready for experimenting
> with.
To make a more compact display I tried putting the site in a narrow
window. Unfortunately below 800 pixels its unreadable.
potappo
<johnj...@johnjbarton.com> wrote:
> Could the first part of the title be read only or at least not edited
> with the rest?
Overriding title is important for l10n to translate English title etc.
See
http://developer.mozilla.org/en/docs/MDC:MediaWiki_Extensions#Title_Override_Extension
But, overriding title may be clear by using the template or extension.
Adam Kowalczyk
>> Click on "More Options" then "Pages that link here".
> Umm, what More Options? I see
> http://img381.imageshack.us/img381/3775/tempey6.png It's not under Site
> Tools, nor Languages.
>
You have to log in to see that drop down menu. It is shown next to
"History".
- Adam
Sheppy
wrote:
> Sheppy wrote:
> > We now have the new version of MDC up and ready for experimenting
> > with.
>
> The text is hard to read because its contrast is too low. The
> information is hard to gather because there is too much whitespace.
Can you give me examples of cases where there's too much whitespace?
I think it's nicely easy to read. The contrast is really good for me,
but I'm not looking at your particular monitor. Having the text be
less than totally black makes it easier on most people's eyes. We did
already darken it some once because the original text color was too
light for several people.
> Some blue text without underlines are links. Some blue text is
> underlined. Some blue text is not a link. Some text is purple and seems
> to mean "this is a link but ha ha, there is no information on the linked
> page". This inconsistency is perplexing, but the biggest real problem is
> the links that don't link. Please don't link to dead pages.
I could use examples of where you see these issues.
As for linking to "dead pages," this is a feature of wikis. Links are
created to indicate articles that should exist in the hope that
someone will write them. This isn't something that will change. Feel
free to contribute content so those pages aren't missing anymore.
Most of your comments are general documentation issues not really
related to the new wiki, so I'm going to table them for the moment,
other than to say if they bother you, change them. :)
Sheppy
wrote:
Define "unreadable," please. A screenshot would be helpful. I find
it quite usable even down below 600 pixels wide. Not ideal,
certainly, but usable.
Sheppy
wrote:
> Sheppy wrote:
> > On Jul 1, 3:57 am, Mook <mook.moz+nntp.news.mozilla....@gmail.com>
> > wrote:
> >> #addObserver.28.29
> >> Whitespace import is whacked; the indenting seems too wide. Doubled?
>
> > I don't see anything wrong here. What looks too wide?
>
> Ah, it looks like my Courier is busted (wtf?). Each space is a DBCS
> wide space, for some odd reason. Will be keeping track of this
> separately from MDC (since that's probably a local problem).
>
> >>http://devmo.dekiwiki.mozilla.org/Special:Search?search=concat
> >> The first result says concat, but no sign of what namespace/context.
> >> That kinda sucks ;)
>
> > Well, not sure what namespace or context you want. It's an article
> > called "concat" :)
>
> Well, the old Nutch search would say things like "Core JavaScript 1.5
> Reference:Global Objects:Array:concat - MDC" instead. So I can tell
> what sort of area I'm looking in (JS String? JS Array? XSLT?).
But the "concat" article you mention is actually an article whose
entire title is "concat" -- at least, that's what it appears to be.
> >>http://devmo.dekiwiki.mozilla.org/en/XUL/Attribute/class
> >> There's no obvious way to figure out what links here (i.e. what sorts of
> >> things attributes/properties apply to). (Yes, that's useful on the
> >> mediawiki)
>
> > Click on "More Options" then "Pages that link here".
>
> Umm, what More Options? I seehttp://img381.imageshack.us/img381/3775/tempey6.pngIt's not under Site
> Tools, nor Languages.
"More Options" is apparently only available if you're logged in. I'll
look into whether that can be changed.
AC
> On Jul 1, 11:36 am, Mook wrote:
>> Sheppy wrote:
>>>> http://devmo.dekiwiki.mozilla.org/Special:Search?search=concat
>>>> The first result says concat, but no sign of what namespace/context.
>>>> That kinda sucks ;)
>>> Well, not sure what namespace or context you want. It's an article
>>> called "concat" :)
>> Well, the old Nutch search would say things like "Core JavaScript 1.5
>> Reference:Global Objects:Array:concat - MDC" instead. So I can tell
>> what sort of area I'm looking in (JS String? JS Array? XSLT?).
>
> But the "concat" article you mention is actually an article whose
> entire title is "concat" -- at least, that's what it appears to be.
>
There are more than one JS concat articles. mook referred to the array
page, sheppy referred to the disambiguation page.
The problem appears to be that the title of dekiwiki pages does not
include the topic context path, while the old one did, so it is not the
fault of the search but the fault of the pages.
Old mediawiki/nutch
http://developer.mozilla.org/en/docs/Special:Nutch?language=en&start=0&hitsPerPage=10&query=concat&fulltext=Search
returns 47 titles including:
(function(){
EXSLT:str:concat - MDC
Category:Disambiguation - MDC
(sheppy)concat - MDC
XPath:Functions:concat - MDC
Category:XSLT - MDC
EXSLT - MDC
(mook) Core JavaScript 1.5 Reference:Global Objects:Array:concat - MDC
Transforming XML with XSLT - MDC
XPath:Functions - MDC
...
New dekiwiki search
http://devmo.dekiwiki.mozilla.org/Special:Search?search=concat
returns 20 titles including
concat
concat
concat
concat
concat
Functions
EXSLT
The Netscape XSLT/XPath Reference
...
While it may be nice that the concat articles appear first, they are not
disambiguated as in the old mediawiki search.
Q. Would they still appear first if 'concat' was the first title word
and the context path appeared after it in the title?
If so, then re-titling articles this way might produce a dekiwiki search
concat (Disambiguation)
concat (XPath / Functions)
concat (EXSLT / str)
concat (Core JavaScript 1.5 Reference / Global Objects / String)
concat (Core JavaScript 1.5 Reference / Global Objects / Array)
Functions (XPath)
EXSLT
The Netscape XSLT/XPath Reference (Transforming XML with XSLT)
...
This would be much better disambiguated than the current dekiwiki
results. (Note: the page <title> is not the same as the <H1> title,
which can still be the short title.)
John J. Barton
> On Jul 1, 10:33 am, "John J. Barton" <johnjbar...@johnjbarton.com>
> wrote:
>
> As for linking to "dead pages," this is a feature of wikis. Links are
Sorry, links to dead pages are not a feature of wikis. Any page
anywhere can link to a dead page. When I waste my time waiting for
information that the author did not exist I am unhappy, whether the
author wrote in a wiki or not.
> created to indicate articles that should exist in the hope that
> someone will write them. This isn't something that will change. Feel
> free to contribute content so those pages aren't missing anymore.
If you don't have time to completely document something in a wiki, feel
free to stop and be proud of what you did accomplish. But don't make
other people do extra work because your ambition exceeded your time.
>
> Most of your comments are general documentation issues not really
> related to the new wiki, so I'm going to table them for the moment,
> other than to say if they bother you, change them. :)
Rather than taking my time to remove links to pages that don't exist,
I'd appreciate it if contributors would not add those links in the first
place.
John.
Seven...@gmail.com
> Oh, I probably should have mentioned that -- all passwords on the
> current test machine were reset to be empty, since MindTouch did the
> conversion for us and was not under NDA, we didn't want to chance
> exposing anyone's passwords. In addition, all email addresses were
> emptied out too, for the same reason. Just log in using an empty
> password and change it using the preferences for now. The real
> passwords and email addresses will be migrated over once we go live
> for real.
I'm unable to log in with or without a password.
Brett Zamir
(such as an orange link), admitting to the absence of information does
not indicate a shortcoming. On the contrary, it itself is also a piece
of information.
Wikipedia itself was built up because of such links. Its participants
both felt inspired to contribute to empty pages, as well as created
skeletons which were in turn populated by those who started the pages
and those who visited them. It is a form of communication and a
reminder, even for the person who added the empty links.
Here at MDC, I want to know what is missing and what areas I can
explore, elsewhere if necessary. Not having that information leads to a
false sense of security and complacency. I recently came to a page which
was created but only said it was a placeholder; the community is not
easily made aware of such cases (unless they have a stub category) and
without at least a link to a specification, it is a waste of someone's
time to come to such a page. The orange links (when the number of them
is not overwhelming) function as a reminder (even more than a stub
category) that we have to do something about them, (while we at least
know we don't need to visit them).
Moreover, and perhaps most significantly, if empty links are allowed, it
is possible for the "What links here" feature to have meaning at a later
date, since a number of authors were not cowed into avoiding adding this
information because they didn't have the time. To take one example, I
recently added a simple page
http://developer.mozilla.org/en/docs/DOM:ProcessingInstruction due to it
being relevant for another page I started and was able to find other
pages already linking to that page (which of course have now become
valid and useful links), and this was only possible because people felt
comfortable adding those empty links in the first place. If not, I'd
have to go hunting around for any page where it'd be relevant to add a
page to this one.
That all being said, I do agree that if main access points have large or
perhaps even small gaps, it does look too ambitious, and even depressing
for would-be contributors who think that the site is trying to get
others to do their work for them in such basic areas without doing any
themselves. And hopefully some concerted efforts can be made to fill in
at least the most popular wanted pages:
http://developer.mozilla.org/en/docs/Special:Wantedpages .
I think there is a balance between being too ambitious and not ambitious
enough.
best wishes,
Brett
Seven...@gmail.com
including the low contrast/desaturated colors.
The way search results are displayed is a problem. To better
demonstrate, take a look at what a search for toString looks like,
this time qualified by a language parameter:
http://devmo.dekiwiki.mozilla.org/Special:Search?search=toString&language=en
There is no context for the results, since the article snapshots are
displaying raw markup, which is next to useless for any sufficiently
content-full wiki. I can't say I endorse the suggestion to renaming
page titles to _re_include context, as that's what we've been trying
to move away from, and that would be an awkward and redundant way to
take care of things in light of the functioning breadcrumbs. A much
simpler, natural solution would be to put the path under the title,
akin to Google's search results, albeit closer to the top; e.g, the
result for toString on String instances would appear as
toString
in /En/Core JavaScript 1.5 Reference/Global Objects/String
113 words - Updated 9 months ago
{{ page.toc }} Summary Returns a stri...
How seriously has the roundtripping issue been looked into? This would
seem like a showstopper to me if the WYSIWYG editor is going to be
screwing with article contents that it can't intelligently parse,
since it would have to be dealt with rather annoyingly in subsequent
edits. This is likely to drive away would-be or drive-by contributors
if they try to correct something and end up breaking the page.
On Jul 4, 11:21 am, "John J. Barton" <johnjbar...@johnjbarton.com>
I'd just like to reiterate that this topic is for issues directly
related to the Deki changeover. Discussion about MDC policies and the
contents of the documentation itself shouldn't go here; if you'd like,
you should create a separate topic to discuss this, but I can almost
guarantee that this behavior isn't going to change.
potappo
Screenshot is the following url.
http://www.flickr.com/photos/23976615@N03/2637890566/
The reason is the font-family of <#pageText pre> and <#pageText code> is
font-family:Andale Mono",Courier,"Courier New",monospace
In my Windows, "Andale Mono" is not installed, so Courie is used,
but Windows's Courie is only raster font, not scalable. See
http://www.angelfire.com/al4/rcollins/style/fonts.html.
Like the infomation of this site, please change css code as the following.
font-family:"Andale Mono","Courier New",Courier,monospace
--
potappo
Sheppy
wrote:
> Sheppy wrote:
> > On Jul 1, 10:33 am, "John J. Barton" <johnjbar...@johnjbarton.com>
> > wrote:
>
> > As for linking to "dead pages," this is a feature of wikis. Links are
>
> Sorry, links to dead pages are not a feature of wikis. Any page
> anywhere can link to a dead page. When I waste my time waiting for
> information that the author did not exist I am unhappy, whether the
> author wrote in a wiki or not.
I'm afraid I disagree. I find these links to be an invaluable aid, in
that it helps keep track of what content has yet to be written. It's
incredibly important to know when there are articles that still need
to be written, and I like this approach.
John J. Barton
> Wikipedia itself was built up because of such links. Its participants
> both felt inspired to contribute to empty pages, as well as created
> skeletons which were in turn populated by those who started the pages
> and those who visited them. It is a form of communication and a
> reminder, even for the person who added the empty links.
I wonder what evidence you have to support this idea. Wikipedia is
successful, no doubt. I attribute this to wiki technology and the
williness of Wikipedia to host, organize, and police the site. Dead
links would not be on the list. I wonder how many MDC users were
inspired by dead links.
But leaving this aside, consider a better implementation if you goal is
to inspire. Rather than forcing users to wait for a page load to find
out that nothing is there, how about a simple popup suggesting that this
topic is important and as a reader you are in a great position to start
the description with what ever you know? Then put the link to the new
page as an Start This Page Now.
John.
Benoit Leseul
<johnj...@johnjbarton.com> wrote:
> But leaving this aside, consider a better implementation if you goal is
> to inspire. Rather than forcing users to wait for a page load to find
> out that nothing is there, how about a simple popup suggesting that this
> topic is important and as a reader you are in a great position to start
> the description with what ever you know? Then put the link to the new
> page as an Start This Page Now.
Sorry, but could it just be a presentational issue? Why do you feel
the need to click on those links to find out that the content is not
written yet? Is the different color not enough? Then maybe the
stylesheet could be changed to add some icon (a pen) or some content
("Create this page") next to the links leading to new edit pages. This
should be pretty easy, they all have the special class "new". You
could also use an user stylesheet or a greasemonkey script for this
purpose.
--
Benoît
Sheppy
wrote:
There's hardly any need to load the page to know there's no content
there, because the nonexistent articles' links are styled differently
from the others.
Sheppy
full path of articles, to MindTouch as well as the author of our skin.
I don't know whether it's a skin issue or one in the Deki code
itself. I'll make sure this gets addressed as soon as possible.
Thanks!
Sheppy
> How seriously has the roundtripping issue been looked into? This would
> seem like a showstopper to me if the WYSIWYG editor is going to be
> screwing with article contents that it can't intelligently parse,
> since it would have to be dealt with rather annoyingly in subsequent
> edits. This is likely to drive away would-be or drive-by contributors
> if they try to correct something and end up breaking the page.
Can you give me some specific examples of what problem you have here?
I've not noticed any issue here with the types of testing I've done,
so some good step-by-step instructions to reproduce this would be a
huge help for me.
Thanks in advance,
Sheppy
wrote:
> Sheppy wrote:
> > We now have the new version of MDC up and ready for experimenting
> > with.
>
> and the editor seems decent. Slow but that is partly because it has a
> bunch of errors like
> Error in parsing value for property 'filter'. Declaration dropped.;
> that slow it down.
I don't see these errors. Can you get me a screenshot?
>
> At the bottom of the edit buffer is a bunch of markup like:
>
> {{template.JSInherits("Function", "Properties", "caller", "constructor",
> "length", "name")}}
This is the same as inserting templates in the current MediaWiki based
site. You have to edit those as code; there's not really a logical
way to do those in WYSIWYG form.
> The pages use the term "instance" and the term "object". Pick one.
> Personally I vote not to use the word "instance" at all because it is
> widely used as "instance of a class" which is not true in Javascript.
Feel free to edit the corresponding page on the current MDC. :)
Seven...@gmail.com
I was not referring to any specific problem I had observed (as I was
unable to login), but asking about the ability of the WYSIWYG editor's
ability to handle this. After a few hasty glances around, I have
noticed, however, that the editor seems to be inserting paragraphs
consisting of a single non-breaking space after the page titles when
switching to source view.
To reproduce:
1. Visit any article, e.g., the JavaScript Reference:
http://devmo.dekiwiki.mozilla.org/En/Core_JavaScript_1.5_Reference
2. Switch to source view
3. Observe the presence of such a paragraph following the first
heading element that did not seem to exist in the page or the rich-
text editor.
4. Switch out of source view, back to rich-text view.
5. Observe that this paragraph has persisted and now appears as
unattractive whitespace.
Also, the heading elements in the rich-text view do not reflect the
elements used. The heading described as "h2" is actually an h3
element. I realize that this is due to the overloaded h1 element
serving as the title, but this is still the wrong behavior.
Also, the h3 element is incorrectly used; it should be h2. This is our
own fault, as I believe almost no one marks up headings in MediaWiki
using
= Heading =
syntax to begin with, but instead use
== Heading ==
and lower.
We could start changing these manually after the move, but it would
probably be easy enough to write a script. This should actually
probably be a part of the Deki migration tools, since I think other
MediaWiki wikis do the same--I know Wikipedia marks up most headings
by far in this way.
What is the purpose of the "Extensions List" anchor under the editor
that points to a zero-byte file?
Not displaying the "Edit this page" and "More options" links for users
not logged in is a mistake. It's not obvious that this is a wiki to
readers not otherwise already in-the-know. This includes both those
users already familiar with "those websites like Wikipedia" and those
for whom the word "wiki" means nothing. Disabling the edit links is
debatable, but doing the same for "more options" is just annoying,
considering authentication isn't even necessary for things like What
links here and access to the talk page.
The significance of the colors for empty pages has disappeared for
talk page links. It's no longer obvious whether comments exist on a
page without actually checking.
I'd like to echo the sentiment that the dropdowns are frustrating from
an accessibility standpoint, as well as general usability. Number of
clicks is important.
The Deki analog of MediaWiki's Special:Specialpages is non-existent as
far as I can tell, and that goes for the tools that should appear on
that page, e.g., broken redirects, double redirects, dead-end pages,
unused files, unused templates, and wanted pages.
Diff is terrible.
Preferences are lacking as well. Desirable additions include ability
to turn of automatic highlighting for pages linked from search results
and the ability to retain a preferred language setting.
Since templates are not qualified by a language, but are shared across
the entire wiki, which breaks localization of template pages. I have a
vague notion that this is fixable with DekiScript.
Revisiting the rich-text editor issues, it generates some ugly code.
It wouldn't be too terrible if it didn't remangle code which has been
explicitly fixed with inserted whitespace to make things such as
definition lists more readable.
The search doesn't place enough gravity on page titles. "Core
JavaScript 1.5 Reference" doesn't even yield that article on the first
page of results.
Mook
> Can you give me some specific examples of what problem you have here?
> I've not noticed any issue here with the types of testing I've done,
> so some good step-by-step instructions to reproduce this would be a
> huge help for me.
>
http://devmo.dekiwiki.mozilla.org/User:Mook_test/Roundtripping
I had entered each <dt>/<dd> tag on its own line with two-space indent;
all newlines got stripped out.
(I found this when editing the songbird wiki, actually. It turns out
that MSVC8 has the best XML reformatting options at my disposal :p )
Random unrelated: I was silly and lost the "mook_test" account password
(it's a test db anyway, it doesn't matter); so I created a new
"mook_test_" account (trailing underscore) and deki decided to use the
same user page. Probably should disable user names with trailing
underscores :)
--
Mook
potappo
can not be localized.
When mediaWiki based, it can be localized, is it a regression?
Surely names of month can be translated, but, in Japanese,
only translating a name of month make date unreadable (e.g. 6 7月 2008).
Sheppy
> In now dekiwiki code, date format (used Special:Recentchanges etc.)
> can not be localized.
> When mediaWiki based, it can be localized, is it a regression?
>
> Surely names of month can be translated, but, in Japanese,
> only translating a name of month make date unreadable (e.g. 6 7月 2008).
>
I've filed a bug with MindTouch on this one:
http://bugs.developer.mindtouch.com/view.php?id=4457
Sheppy
wrote:
> Sheppy wrote:
> > Can you give me some specific examples of what problem you have here?
> > I've not noticed any issue here with the types of testing I've done,
> > so some good step-by-step instructions to reproduce this would be a
> > huge help for me.
>
> I was mostly complaining about changes to whitespace:http://devmo.dekiwiki.mozilla.org/User:Mook_test/Roundtripping
> I had entered each <dt>/<dd> tag on its own line with two-space indent;
> all newlines got stripped out.
How serious a problem is this? It doesn't sound like it would affect
the rendered output at all.
> Random unrelated: I was silly and lost the "mook_test" account password
> (it's a test db anyway, it doesn't matter); so I created a new
> "mook_test_" account (trailing underscore) and deki decided to use the
> same user page. Probably should disable user names with trailing
> underscores :)
I've filed a bug with MindTouch: http://bugs.developer.mindtouch.com/view.php?id=4458
Mook
> On Jul 5, 9:30 pm, Mook <mook.moz+nntp.news.mozilla....@gmail.com>
> wrote:
>> Sheppy wrote:
>>> Can you give me some specific examples of what problem you have here?
>>> I've not noticed any issue here with the types of testing I've done,
>>> so some good step-by-step instructions to reproduce this would be a
>>> huge help for me.
>> I was mostly complaining about changes to whitespace:http://devmo.dekiwiki.mozilla.org/User:Mook_test/Roundtripping
>> I had entered each <dt>/<dd> tag on its own line with two-space indent;
>> all newlines got stripped out.
>
> How serious a problem is this? It doesn't sound like it would affect
> the rendered output at all.
>
(For the thing I was doing, I ended up just saving a file on the local
machine that had the original source, instead. That is, completely
defeated the whole edit-by-anybody purpose of a wiki.)
>> Random unrelated: I was silly and lost the "mook_test" account password
>> (it's a test db anyway, it doesn't matter); so I created a new
>> "mook_test_" account (trailing underscore) and deki decided to use the
>> same user page. Probably should disable user names with trailing
>> underscores :)
>
> I've filed a bug with MindTouch: http://bugs.developer.mindtouch.com/view.php?id=4458
Thanks!
--
Mook
Sheppy
wrote:
> Doesn't affect output at all, just sucks when you try to edit it later.
> (For the thing I was doing, I ended up just saving a file on the local
> machine that had the original source, instead. That is, completely
> defeated the whole edit-by-anybody purpose of a wiki.)
I've submitted a ticket with Deki related to this issue:
http://bugs.developer.mindtouch.com/view.php?id=4459
Sheppy
> I was not referring to any specific problem I had observed (as I was
> unable to login), but asking about the ability of the WYSIWYG editor's
> ability to handle this. After a few hasty glances around, I have
> noticed, however, that the editor seems to be inserting paragraphs
> consisting of a single non-breaking space after the page titles when
> switching to source view.
I've filed a ticket with MindTouch:
http://bugs.developer.mindtouch.com/view.php?id=4460
> Also, the heading elements in the rich-text view do not reflect the
> elements used. The heading described as "h2" is actually an h3
> element. I realize that this is due to the overloaded h1 element
> serving as the title, but this is still the wrong behavior.
I'm not sure how to address this. I think it's reasonable the way it
is, despite not being entirely accurate. What would you propose?
>
> Also, the h3 element is incorrectly used; it should be h2. This is our
> own fault, as I believe almost no one marks up headings in MediaWiki
> using
Also filed:
http://bugs.developer.mindtouch.com/view.php?id=4461
> What is the purpose of the "Extensions List" anchor under the editor
> that points to a zero-byte file?
I admit I don't know. I've asked. :)
> Not displaying the "Edit this page" and "More options" links for users
> not logged in is a mistake.
Good point. I've requested that this be changed if possible; should
just be a relatively easy skin revision.
> The significance of the colors for empty pages has disappeared for
> talk page links. It's no longer obvious whether comments exist on a
> page without actually checking.
Reported.
http://bugs.developer.mindtouch.com/view.php?id=4462
> I'd like to echo the sentiment that the dropdowns are frustrating from
> an accessibility standpoint, as well as general usability. Number of
> clicks is important.
We debated this for a long time (a lot of people) and it was decided
to go this route in order to avoid clutter on the site. It's
something we can revisit later after we get launched and some other
stuff dealt with if it continues to frustrate people down the line.
> The Deki analog of MediaWiki's Special:Specialpages is non-existent as
> far as I can tell, and that goes for the tools that should appear on
> that page, e.g., broken redirects, double redirects, dead-end pages,
> unused files, unused templates, and wanted pages.
I'll look into this. Many of these items do exist but it looks like
some of them may require advanced privileges to get access to.
> Diff is terrible.
Can you be more specific about what you dislike about the diff?
> Preferences are lacking as well. Desirable additions include ability
> to turn of automatic highlighting for pages linked from search results
> and the ability to retain a preferred language setting.
There is a preferred language setting in the user preferences
already. Being able to turn off the automatic highlighting would be
nice though. See:
http://bugs.developer.mindtouch.com/view.php?id=4463
> Since templates are not qualified by a language, but are shared across
> the entire wiki, which breaks localization of template pages. I have a
> vague notion that this is fixable with DekiScript.
Yes, it is. This is one area where we'll have a bit of learning
curve.
> The search doesn't place enough gravity on page titles. "Core
> JavaScript 1.5 Reference" doesn't even yield that article on the first
> page of results.
Filed a ticket with MindTouch:
http://bugs.developer.mindtouch.com/view.php?id=4464
Thanks for all the input! Very good stuff!
Sheppy
> > Can you give me some specific examples of what problem you have here?
> > I've not noticed any issue here with the types of testing I've done,
> > so some good step-by-step instructions to reproduce this would be a
> > huge help for me.
>
> I was mostly complaining about changes to whitespace:http://devmo.dekiwiki.mozilla.org/User:Mook_test/Roundtripping
> I had entered each <dt>/<dd> tag on its own line with two-space indent;
> all newlines got stripped out.
OK, according to MindTouch, it's going to be very hard to fix this
behavior. The XHTML you enter is processed through a filter to ensure
that it's real XHTML instead of just HTML, and is then filtered to
make sure there aren't any potential XSS issues. These filters are
the reason why whitespace is being twiddled with, and I gather that
they're third party filters, so it's not necessarily something
MindTouch can easily address.
However, there's a bug filed, so hopefully this will be looked at.
Sheppy
> can not be localized.
> When mediaWiki based, it can be localized, is it a regression?
>
> Surely names of month can be translated, but, in Japanese,
> only translating a name of month make date unreadable (e.g. 6 7月 2008).
OK, this is a skinning issue. You can localize the date format by
putting the appropriate date format string into the resources file.
John J. Barton
> On Jul 1, 11:35 am, "John J. Barton" <johnjbar...@johnjbarton.com>
> wrote:
>> Sheppy wrote:
>>> We now have the new version of MDC up and ready for experimenting
>>> with.
>> I editedhttp://devmo.dekiwiki.mozilla.org/En/Core_JavaScript_1.5_Reference/Gl...
>> and the editor seems decent. Slow but that is partly because it has a
>> bunch of errors like
>> Error in parsing value for property 'filter'. Declaration dropped.;
>> that slow it down.
>
> I don't see these errors. Can you get me a screenshot?
Error in parsing value for property 'filter'. Declaration dropped.
http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/default/fck_editor.css
Line 154
Error in parsing value for property 'filter'. Declaration dropped.
http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/default/fck_editor.css
Line 160
Error in parsing value for property 'filter'. Declaration dropped.
http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/default/fck_editor.css
Line 263
Error in parsing value for property 'filter'. Declaration dropped.
http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/default/fck_editor.css
Line 280
Unknown property 'text-overflow'. Declaration dropped.
http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/default/fck_editor.css
Line 352
Error in parsing value for property 'filter'. Declaration dropped.
http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/default/fck_editor.css
Line 387
Unknown property 'text-overflow'. Declaration dropped.
http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/default/fck_editor.css
Line 399
Error in parsing value for property 'filter'. Declaration dropped.
http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/default/fck_editor.css
Line 415
But really I think the editor is decent.
Eric H. Jung
Filter is IE-specific CSS. Unless they have different CSS for different user-agents, that's going to be really really really difficult to "fix". Can't speak to text-overflow.
Mike Shaver
<johnj...@johnjbarton.com> wrote:
> and the editor seems decent. Slow but that is partly because it has a
> bunch of errors like
> Error in parsing value for property 'filter'. Declaration dropped.;
> that slow it down.
I doubt that slows it down much, unless the Error Console is open.
(Those are really reported to the console as warning messages; the
"error" string is unfortunate.)
CSS is designed to be forward compatible that way, skipping unknown
constructs, like with unknown tags in HTML. I don't think we should
report those warnings to the console by default at all, but it took a
while for me to get them downgraded to warning from error, so progress
on that front may be slow.
Mike
John J. Barton
> On Tue, Jul 1, 2008 at 11:35 AM, John J. Barton
> <johnj...@johnjbarton.com> wrote:
>> and the editor seems decent. Slow but that is partly because it has a
>> bunch of errors like
>> Error in parsing value for property 'filter'. Declaration dropped.;
>> that slow it down.
>
> I doubt that slows it down much, unless the Error Console is open.
> (Those are really reported to the console as warning messages; the
> "error" string is unfortunate.)
Yes, I realized later my information might not be that useful. In
addition to the error console, I print every error twice to
window.dump() (to debug firebug) and Firebug formats them in to HTML.
John.
Sheppy
wrote:
> Sheppy wrote:
> > On Jul 1, 11:35 am, "John J. Barton" <johnjbar...@johnjbarton.com>
> > wrote:
> >> Sheppy wrote:
> >>> We now have the new version of MDC up and ready for experimenting
> >>> with.
> >> I editedhttp://devmo.dekiwiki.mozilla.org/En/Core_JavaScript_1.5_Reference/Gl...
> >> and the editor seems decent. Slow but that is partly because it has a
> >> bunch of errors like
> >> Error in parsing value for property 'filter'. Declaration dropped.;
> >> that slow it down.
>
> > I don't see these errors. Can you get me a screenshot?
>
> Line 154
> Error in parsing value for property 'filter'. Declaration dropped.http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/...
> Line 160
> Error in parsing value for property 'filter'. Declaration dropped.http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/...
> Line 263
> Error in parsing value for property 'filter'. Declaration dropped.http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/...
> Line 280
> Unknown property 'text-overflow'. Declaration dropped.http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/...
> Line 352
> Error in parsing value for property 'filter'. Declaration dropped.http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/...
> Line 387
> Unknown property 'text-overflow'. Declaration dropped.http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/...
> Line 399
> Error in parsing value for property 'filter'. Declaration dropped.http://devmo.dekiwiki.mozilla.org/editor/fckeditor/core/editor/skins/...
> Line 415
>
> But really I think the editor is decent.
I've let MindTouch know about it. Thanks. :)
Benoit
> Filter is IE-specific CSS. Unless they have different CSS for different user-agents, that's going to be really really really difficult to "fix". Can't speak to text-overflow.
This filter hack is a well-known way to make PNGs with transparency work
in IE6. The warning is typically resolved by including an IE6-specific
stylesheet (IE7 has a somewhat decent PNG support) using conditional
comments like [if lte IE 6]. See http://www.quirksmode.org/css/condcom.html
By the way, I didn't get any answer on my feedback from about a week
ago, it seems to have been overlooked. Here is the link in Google
Groups: http://groups.google.com/group/mozilla.dev.mdc/msg/1a8c3a69b602798e
(sorry, I wanted to post this on Sheppy's blog, but comments are closed
there)
--
Benoit
FrenchMozilla l10n Team
Sheppy
> First, about the theme. I find it nice, probably even more readable than
> the previous one, and easier on the eye. But what I don't like as an
> editor are the drop-downs for languages, options and site tools. I think
> they should be made more accessible when logged in, or maybe we need
> separate user themes like we have in MediaWiki.
The idea was to make things less cluttered. It accomplishes that goal
but I agree that there are some issues with it. I'd like to leave it
as is for a while to see what people think of it after using it for a
while, then look into doing another revision to the theme to take into
account how people feel about it after using it for a while.
> I can't find the 'Follow linked changes' tool, even under "More
> options". This is a very important tool for localizers to track changes
> directly linked from the Main page or the "Firefox N for developers".
> Even more so, since I expect the bots will stop making reports likehttp://mdc.mozilla.gr.jp/bot/relst/fx3docs.cgifor a while (until they
> are updated to work with DekiWiki).
You know, I'd never seen this option before, but I can understand why
it's useful. I've filed a ticket with MindTouch asking them to
consider adding this in the future:
http://bugs.developer.mindtouch.com/view.php?id=4479
> I think the Users pages is mostly useless. You have to type the exact
> user name of someone in the search box to find it and there is no means
> to browse the list than 50 names at a time, when there are thousands of
> them. Even if you happen to type the right name in the search box, you
> end up on the User page, where there is actually no link to this user's
> contributions.
Excellent point. Filed ticket:
http://bugs.developer.mindtouch.com/view.php?id=4480
> I find the Popular pages link very nice, since you can now compare the
> popularity of all articles in all languages at once. But a language
> filter would still be useful in some cases.
I expect we'll find a few more issues like these; the polyglot support
is new and there are some gaps. I've filed ticket:
http://bugs.developer.mindtouch.com/view.php?id=4481
> When editing a page, I miss previewing my changes, viewing a diff of my
> changes, and a backlink to the unedited page (if I want to check how it
> was before editing by opening it in a new tab).
> Also, most of the top drop-downs are unusable and unrelated to the
> existing text (fonts, sizes, styles, ...)
Tickets have been filed for previews and stuff like that, and the drop-
downs should be working now. We've got a request in to MindTouch to
make it possible to configure the toolbar without conflicting with
software updates, and that feature is coming soon. This will let us
fine-tune the toolbar more to our needs.
> When following a redirection, we get a link to the Redirect page (which
> is great), but not to the actual page. If I want to send a link to
> someone and I came to the article by a redirection, I can only link to
> the redirection :-/
> Example:http://devmo.dekiwiki.mozilla.org/en/Online%2f%2fOffline_Events
> The old skin has an "Article" link in the header to do this, but you
> could simply use the title as a link to the current article (like on
> most blogs), or the last part of the breadcrumbs line.
Hm, this I'll have to poke at some more. :)
> Also related to redirections, the "What links here" tool don't seem to
> show redirections. See for examplehttp://devmo.dekiwiki.mozilla.org/en/Firefox_2_for_developerswhich has
> only three direct incoming links, but dozens with the [[Firefox 2]]
> redirect which are not shown in the special page.
Filed: http://bugs.developer.mindtouch.com/view.php?id=4482
> I don't like the new diffs at all. They should (at least optionnaly) be
> made contextual, I don't want to go trough the whole page to find a two
> words change.
> Worse, they are shown inline instead of the two versions side by side,
> which mades it very difficult to understand the meaning of what was
> changed, and almost impossible to cut and paste the new version as a
> base for translation.
> Seehttp://devmo.dekiwiki.mozilla.org/index.php?title=En%2FOnline_and_off...
> for an example of an unreadable diff on a sentence where the only common
> words are "the", "this" and "in". And it is not, by far, the worst
> example of that.
Agreed wholeheartedly. See ticket:
http://bugs.developer.mindtouch.com/view.php?id=4483
> And finally, there are several conversion errors onhttp://devmo.dekiwiki.mozilla.org/en/XUL/button(and other pages from
> the XUL reference), like this:
>
> line 1, column 55: ")" expected
I've emailed MindTouch about this one.
> Sorry if most of my comments sound negative, I mostly focused on what I
> perceived as regressions. That doesn't mean that there are no useful new
> features, but I don't understand why some were actually removed in the
> process (I found out in the source that many parts of Deki are actually
> based on MediaWiki itself).
I'm quite excited to get so much useful feedback! I don't know how
much of this stuff will be addressed before we launch, but MindTouch
seems to be committed to making us happy for the long haul.
Eric Shepherd
Developer Documentation Lead
Mozilla Corporation
Sheppy
> Eric H. Jung wrote:
> > Filter is IE-specific CSS. Unless they have different CSS for different user-agents, that's going to be really really really difficult to "fix". Can't speak to text-overflow.
>
> This filter hack is a well-known way to make PNGs with transparency work
> in IE6. The warning is typically resolved by including an IE6-specific
> stylesheet (IE7 has a somewhat decent PNG support) using conditional
>
> By the way, I didn't get any answer on my feedback from about a week
> ago, it seems to have been overlooked. Here is the link in Google
> Groups:http://groups.google.com/group/mozilla.dev.mdc/msg/1a8c3a69b602798e
> (sorry, I wanted to post this on Sheppy's blog, but comments are closed
> there)
Hm, comments aren't closed on my blog... that's odd.
As for your previous post, I replied to it earlier today, finally,
after missing it the first time around.
Atsushi Shimono
Hash: SHA512
hi,
four minor points.
1. url
I think i've heard that official url of devmo should be
http://developer.mozilla.org/<lang>/ , such as
http://developer.mozilla.org/ja/, when we've made some leaflets for FF2
release.
On current test site, <lang> will automatically CAPITALIZED by a server
like
http://devmo.dekiwiki.mozilla.org/En
even if i type in 'en'.
For marketing sides' view, i think it would be nice to get back to
the former format.. (Then, we don't need to change the already created
ones, even if the urls are redirected.)
2. logo
Some people had said about this, but i'd like to re-post this.
Current logo contains '<developer center/>', which looks like a tag of
html or xml. But it's not valid as xml, and should be '<developer_center/>'
or something. :-)
3. RSS feed link
site tools (link on top) => RSS feeds, whose url is
http://devmo.dekiwiki.mozilla.org/Special:ListRss
, lists 'User feeds' contains RSSs of users' contributions and watchlists.
Is this useful??
4. User classification
In MediaWiki, user can get 'bot' flag or so, and filter them at recent
changes. Issn't it supported in Deki?
Sheppy wrote:
>> I can't find the 'Follow linked changes' tool, even under "More
>> options". This is a very important tool for localizers to track changes
>> directly linked from the Main page or the "Firefox N for developers".
>> Even more so, since I expect the bots will stop making reports like
>> http://mdc.mozilla.gr.jp/bot/relst/fx3docs.cgifor a while (until they
>> are updated to work with DekiWiki).
Sorry but now we have definitely NO plan to catch up with DekiWiki.
By current limited research, some of our bots are really hard to
accommodate with DekiWiki, i think.
regards,
- --
Atsushi Shimono - shi...@mozilla.gr.jp
http://www.mozilla.gr.jp/~shimono/blog/
Mozilla-Gumi : Japanese Mozilla Users Group / System Administrator
MDC Japan Project Leader, Bugzilla Localization Working Group Member
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEAREKAAYFAkh2MOkACgkQBygbhFUCKWYZ5QCfcRsGWIDBawBkii6gG++kOu66
FG0AnAnbRWXYn6Ny3qoSSZ7zRfX83oM9
=zvVt
-----END PGP SIGNATURE-----
Sheppy
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> hi,
>
> four minor points.
>
> 1. url
>
> release.
> On current test site, <lang> will automatically CAPITALIZED by a server
> even if i type in 'en'.
This is how MindTouch Deki works; I don't expect it will change. Of
course, when we launch the real site, the server will be
developer.mozilla.org again.
> Some people had said about this, but i'd like to re-post this.
> Current logo contains '<developer center/>', which looks like a tag of
> html or xml. But it's not valid as xml, and should be '<developer_center/>'
> or something. :-)
Wow, that's nitpicky. And nerdy. Nicely done. :)
> site tools (link on top) => RSS feeds, whose url ishttp://devmo.dekiwiki.mozilla.org/Special:ListRss
> , lists 'User feeds' contains RSSs of users' contributions and watchlists.
> Is this useful??
Not sure if it's useful or not. If there are other feeds you'd like
to see offered, suggest them on the MindTouch bug database (or ask me
to do it, since they'll recognize me as representing MDC). :)
> 4. User classification
>
> In MediaWiki, user can get 'bot' flag or so, and filter them at recent
> changes. Issn't it supported in Deki?
I don't know. Can you tell me exactly what you want to do?
Atsushi Shimono
Hash: SHA512
hi,
Sheppy wrote:
>> 1. url
>>
>> I think i've heard that official url of devmo should behttp://developer.mozilla.org/<lang>/ , such ashttp://developer.mozilla.org/ja/, when we've made some leaflets for FF2
>> release.
>> On current test site, <lang> will automatically CAPITALIZED by a server
>> likehttp://devmo.dekiwiki.mozilla.org/En
>> even if i type in 'en'.
>
> This is how MindTouch Deki works; I don't expect it will change. Of
> course, when we launch the real site, the server will be
> developer.mozilla.org again.
So, we must change all leaflets with /en => /En ????
Of cource, it will be redirected. But "/en" will be non-official.
>> site tools (link on top) => RSS feeds, whose url ishttp://devmo.dekiwiki.mozilla.org/Special:ListRss
>> , lists 'User feeds' contains RSSs of users' contributions and watchlists.
>> Is this useful??
>
> Not sure if it's useful or not. If there are other feeds you'd like
> to see offered, suggest them on the MindTouch bug database (or ask me
> to do it, since they'll recognize me as representing MDC). :)
ah. ok for filing to bug database if i find something new to put.
But,, how about the current list. Isn't it useful to show users' RSS links?
Many of them might be spam accounts, we'll never need their links.
>> 4. User classification
>>
>> In MediaWiki, user can get 'bot' flag or so, and filter them at recent
>> changes. Issn't it supported in Deki?
>
> I don't know. Can you tell me exactly what you want to do?
Current "Mgjbot" is flagged as 'bot' at MediaWiki. So, if users look at
the recent changes list (by the default), they do never see the updates by
"Mgjbot" account. For most of all users, the updates of (only) inter-language
links might be a spam. Therefore, i think it's useful to hide them.
As some contributors said on irc or bmo, if new user spam could be hidden by
clicking some link at the recent changes page. We currently have some hide/show
links on their. Of cource, this might be an enhancement, but i think we cannot
do such things, if we remove all flags (or toggle items) from wiki system.
regards,
- --
Atsushi Shimono - shi...@mozilla.gr.jp
http://www.mozilla.gr.jp/~shimono/blog/
Mozilla-Gumi : Japanese Mozilla Users Group / System Administrator
MDC Japan Project Leader, Bugzilla Localization Working Group Member
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEAREKAAYFAkh8oRIACgkQBygbhFUCKWZY8gCcCj+BC0gw9LL2UYGXadJWmQPe
EOwAn1nqX18M9RYHfI3e8eqLQlmknAKe
=yn+y
-----END PGP SIGNATURE-----
Mike Shaver
> So, we must change all leaflets with /en => /En ????
> Of cource, it will be redirected. But "/en" will be non-official.
Your leaflets probably don't have Main_Page on them either, and we
could redirect at any time, but I don't think we've ever been that
concerned with "official" links like that in any case.
>>> 4. User classification
>>>
>>> In MediaWiki, user can get 'bot' flag or so, and filter them at recent
>>> changes. Issn't it supported in Deki?
>>
>> I don't know. Can you tell me exactly what you want to do?
>
> Current "Mgjbot" is flagged as 'bot' at MediaWiki. So, if users look at
> the recent changes list (by the default), they do never see the updates by
> "Mgjbot" account. For most of all users, the updates of (only) inter-language
> links might be a spam. Therefore, i think it's useful to hide them.
Deki supports inter-language linking natively, I believe, since
translations of pages are known to the underlying database. It can
tell that something is a ja translation without the bot needing to
inform it, if I'm recalling correctly. Sheppy probably knows more
about that, too!
Mike
Neil
developer.mozilla.org declares two favicons,
http://developer.mozilla.org/favicon.ico (which is actually a PNG but is
served as image/x-icon so it will create an image document and then
auto-detect as a PNG if you click the link) and
http://developer.mozilla.org/favicon.png (which is a 404). This at least
makes the icon fail to appear in SeaMonkey, as we only search
/favicon.ico if there are no link icons.
devmo.dekiwiki.mozilla.org hardly does any better. It too declares two
favicons, http://devmo.dekiwiki.mozilla.org/favicon.ico (which is
actually a PNG but is served as text/plain) and
http://devmo.dekiwiki.mozilla.org/skins/mozilla/Fox3/favicon.ico (which
really is an ICO but is still served as text/plain). However at least
both icons exist, so one shows up.
Sheppy
The favicon thing should be resolved by the time the Deki version of
MDC rolls live.
Benoit
>> On current test site, <lang> will automatically CAPITALIZED by a server
>> likehttp://devmo.dekiwiki.mozilla.org/En
>> even if i type in 'en'.
>
> This is how MindTouch Deki works; I don't expect it will change.
It seems that language links works correctly now, except in the
breadcrumbs line ("Main Page" and so on). It could cause confusion with
Italian if someone were to start a Lithunanian translation, since "lt"
and "It" would both be used at some places and are very difficult to
tell apart.
More generally, I think we should try to have the automatic
capitalization of titles everywhere disabled. Automatic capitalization
is probably fine for general purpose sites, but for a developer wiki
it's very annoying.
For example, I just created a test page from a "brown" link in the
French wiki where the title was all in lowercase (as it should be for
"table.align"), and the editor uppercased my title as "Table.align". I
had to edit the page again and change the title for it to be correct.
Note that the title is still incorrect in Recent Changes.
Another note on language codes: it seems Simplified Chinese has got the
"cn" tag. That is very wrong since "cn" is a country code and not a
language code (which would be "zh"). What are you going to do with
Traditional Chinese (Taiwan)?
I think we should really stick with
http://wiki.mozilla.org/L10n:Simple_locale_names
Anything else would be dangerous, both politically and technically.
Mike Shaver also wrote:
> Deki supports inter-language linking natively, I believe, since
> translations of pages are known to the underlying database. It can
> tell that something is a ja translation without the bot needing to
> inform it, if I'm recalling correctly. Sheppy probably knows more
> about that, too!
I'm curious about how it is supposed to work. As I said above, I created
a French version for the page "table.align" with a template tag (that I
took from some other page) saying the English version was
en/DOM/table.align:
{{ wiki.languages( { "en": "en/DOM/table.align" } ) }}
Indeed a link was created in the language dropdown in my French
version... but there is still nothing on the English page. Making the
languages links match was the job of the bot and I can't see how Deki is
taking this role.
If we have to put language links manually in every version of the page,
we'll lose a terrible amount of time. This was a very simple example
because there was only one link to one other version, but imagine what
it will mean for someone starting a new translation of the main page and
having to edit 15 versions in other languages!
One last thing, but a big one (sorry): the spellchecker doesn't work in
the edit fields! On a related note, because that's where spelling
suggestions would appear, I also don't like the fact that the editor
hijacks the context menu. That means I can't copy or paste from there,
nor use an extension or a search engine to lookup a word.
--
Benoit
George3
> On Jul 1, 2:56 pm, "Benoit Leseul" <benoit.les...@gmail.com> wrote:
>
>
> > show redirections. See for example http://devmo.dekiwiki.mozilla.org/en/Firefox_2_for_developerswhichhas
> > only three direct incoming links, but dozens with the [[Firefox 2]]
> > redirect which are not shown in the special page.
>
> Filed:http://bugs.developer.mindtouch.com/view.php?id=4482
>
Template "inclusion"s are also not listed in the "what links here" on
Deki.
I searched on "inclusion", "template", etc in the Deki bug tracker and
couldn't find an existing bug about this.
Here's an example (only a few links on this page):
http://devmo.dekiwiki.mozilla.org/index.php?title=Special:Article&type=backlinks&pageid=137229
(...but over 50 on the current devmo:)
http://developer.mozilla.org/en/docs/Special:Whatlinkshere/Template:fx_minversion_inline
-George3
Atsushi Shimono
Hash: SHA512
hi,
Mike Shaver wrote:
>> So, we must change all leaflets with /en => /En ????
>> Of cource, it will be redirected. But "/en" will be non-official.
>
> Your leaflets probably don't have Main_Page on them either, and we
> could redirect at any time, but I don't think we've ever been that
> concerned with "official" links like that in any case.
In our leaflets, all urls are http://developer.mozilla.org/ja/,
so they don't include Main_Page (or so) nor '/docs/'.
Mozilla Japan's marketing said that they are planning to re-new
their official leaflets at around the end of this year. So, this
issue might be ok with modifying the url on the leaflet at that time.
>>>> 4. User classification
>>>>
>>>> In MediaWiki, user can get 'bot' flag or so, and filter them at recent
>>>> changes. Issn't it supported in Deki?
>>> I don't know. Can you tell me exactly what you want to do?
>> Current "Mgjbot" is flagged as 'bot' at MediaWiki. So, if users look at
>> the recent changes list (by the default), they do never see the updates by
>> "Mgjbot" account. For most of all users, the updates of (only) inter-language
>> links might be a spam. Therefore, i think it's useful to hide them.
>
> Deki supports inter-language linking natively, I believe, since
> translations of pages are known to the underlying database. It can
> tell that something is a ja translation without the bot needing to
> inform it, if I'm recalling correctly. Sheppy probably knows more
> about that, too!
I'll check these.
thanks,
- --
Atsushi Shimono - shi...@mozilla.gr.jp
http://www.mozilla.gr.jp/~shimono/blog/
Mozilla-Gumi : Japanese Mozilla Users Group / System Administrator
MDC Japan Project Leader, Bugzilla Localization Working Group Member
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEAREKAAYFAkiDKoUACgkQBygbhFUCKWaEOACfX6yewLJN8czeoxIfxRve9tbJ
74gAn1yGSsrb4hzgxFXvcNA0m4TwQqrr
=9IsS
-----END PGP SIGNATURE-----
Sheppy
> On Jul 8, 4:15 pm, Sheppy <the.she...@gmail.com> wrote:
>
> > On Jul 1, 2:56 pm, "Benoit Leseul" <benoit.les...@gmail.com> wrote:
>
> > > Also related to redirections, the "Whatlinks here" tool don't seem to
> > > only three direct incoming links, but dozens with the [[Firefox 2]]
> > > redirect which are not shown in the special page.
>
> > Filed:http://bugs.developer.mindtouch.com/view.php?id=4482
>
> Template "inclusion"s are also not listed in the "what links here" on
> Deki.
> I searched on "inclusion", "template", etc in the Deki bug tracker and
> couldn't find an existing bug about this.
> (...but over 50 on the current devmo:)http://developer.mozilla.org/en/docs/Special:Whatlinkshere/Template:f...
>
> -George3
Thanks! I've filed a ticket with MindTouch.
Nickolay Ponomarev
>> Gecko/2008062606)?
>
> Insert link: I haven't had that problem. I'm running Firefox 3
> release here.
>
Turns out this was due to
http://developer.mozilla.org/skins/common/popups/popup.js being
blocked by Adblock in a common configuration. Since I expect many
contributors use Adblock, deki should detect this situation and tell
the user to disable adblock on developer.mozilla.org instead of just
looking broken.
Nickolay