כלים להקל על עריכת מדיה־ויקי

אני מנהל מספר ויקים על מדיה־ויקי וחבר בעוד כמה (ובאחד פחות…). היום התעופפה לי חצי שעה של עריכה בויקי שניות לפני שלחצתי שמירה בשל תקלת של ×—×—"×™ (את ×”UPS הם דפקו לי לפני חצי שנה בסופת ברקים). בוורדפרס וג'מיל התרגלתי שחברת־החשמל לא יכולה להשבית לי שמחות, אבל פונקציה דומה במדיה־ויקי ×–×” בעיה להפעיל מסיבות רבות. לשואש ×”×™×” אמור להיות מנגנון שמשחזר מקריסה את הטאבים כולל תכני־טפסים אבל הוא לא עבד, אז התקנתי בזמנו את TMP אבל גם הוא לא עושה את העבודה.

אז שינסתי מותני והלכתי לחפש פתרונות לכמה דברים שהציקו לי (אוטומציה, שחזור עריכות מקריסה, עריכה משופרת וכולי). מצאתי בויקיפדיה האנגלית לא מעט כלים ששוה להכיר אבל אין לינק בינוויקי לעברית אז (עוד) לא חיפשתי מה גויר ואם יש המלצות. אני אבדוק אותם בימים הקרובים ואעדכן פה את הפוסט אם אגיע למסקנות. אבדוק עד כמה שאפשר תאימות הדדית וכמובן עברית, אבל אני לא מבטיח להיות יסודי – אני כנראה אעצור כשאמצא לי פתרון עובד. אם יש למישהי עוד עצות אז אתן מוזמנות להמליץ, וכמובן אם תמצאו משהו שאני לא גיליתי או לא הגעתי לבדוק – טופס התגובות במקומו מחכה.

  • WikiEd – ×’'אווה־סקריפט דפדפנים מבוססי גקו ו-וובקיט (בקיצור לא אופרה ואקספלונטר) לסביבת עריכה משופרת של ויקיטקסט בתוך חלונות עריכה של מדיה־ויקי. תורגם לערבית אז בטח טוב גם לעברית, אני אציץ עליו אם יש מה לשנות שם בכיווניות או שהוא יורש אותה מהCSS ונשאר רק לתרגם את המחרוזות, ואם כך למה לא הפרידו את המחרוזות מגוף הסקריפט (אפשר להריץ סקריפט מינימליסטי והסקריפט המעודכן המלא רץ מאתר הבית של הויקיפדיה).

    תוכלו להתקין אותו בגריזמונקי לעצמכם, או בערכת המדיה־ויקי לכל משתמשי הויקי שלכם, או רק באתר המדיה־ויקי החשוב לכם (אם לא ידעתם, אז לכל יוזר במדיה־ויקי יש אפשרות לערוך לעצמו את הCSS האישי ואם מנהל האתר איפשר אז גם להוסיף סקריפטים). כתוב שיש כמה באגים ידועים בשואש 3 שפוגעים בתפקודו, אז אם אהבתם אותו, הצביעו למענם בבאגזילה של מוזילה.

  • אבל ×–×” רק אחד, יש עוד הרבה כלי JS שונים, אם רק ×”×™×” לי זמן לעבור על הכל ולדלות דברים שווים…
  • WikiEditPuffer – תוסף שואש ששומר עותקים מקומיים בזמן עריכה בחלון מדיה־ויקי כל X שניות או Y הקשות – מה שבא קודם. נשאר לכם ארכיון יפה (וגדל במהירות – יש להזהר!) של ערכים שערכתם, בקבצי טקסט קטנים שמהם אפשר לשחזר.
  • שלבו עורך חיצוני כמו Notepad++ או VIM או מה שאתם אוהבים, מתוך השואש.
  • לאזארוס יקים לכם לתחיה טפסים שמתו.
  • עוד רשימה ארוכה של תוספי־שואש, לא כולם ספציפיים דווקא למדיה־ויקי. יש גם לדפדפנים אחרים, אבל מי צריך? 🙂
  • לכל חובבי FUSE בלינוקס, יש את WikipediaFS. ×–×” עושה בדיוק מה שאתם חושבים שזה עושה. ×–×” פסיכי. אני לא מתכוון להתקין את ×–×” 🙂

בפעם אחרת אציץ לראות אם מישהי מכן משתמשת בתוספים בשביל הוורדפרס שלה, לדוגמא סקרייבפייר, שווה? נראה שתומך עברית והוא הרי תוכנה חופשית, אז הא לכם כל משתמשי Live Writer, אתם מוזמנים לעשות הסבה.

13 תגובות בנושא “כלים להקל על עריכת מדיה־ויקי”

  1. סקרייבפייר אכן תומן בעברית. לעבדך הנאמן יצא לבלות זמן מה בהתאמה ובתרגום שלו לעברית לפני זמן רב עוד לפני שקראו לו scribefire. אין לי מושג אם סטטוס התמיכה בעברית נפגע מאז אבל אני מניח שלא. למרות זאת, אני לא בטוח אם הוא באמת יהיה שימושי ל־mediawiki.

    בקשר ל־mediawiki, אני הייתי מנצל את היכולות של greasemonkey ושל HTML5 offline storage בשביל ליצור מערכת לשמירה מקומית של טיוטות שתתלבש על דפי העריכה של מדיה וויקי. זה לא דבר מסובך במיוחד למימוש, ויהיה אכן שימושי מאד למשתמשים.

    להלן רשימת תסריטי גריזמנקי למדיה וויקי. לא ראיתי שם תסריט כפי שתיארתי, אבל אולי WikiEd יכול לבצע זאת.
    http://userscripts.org/tags/mediawiki

    1. לא רמזתי שהוא שימושי לMW, אבל היה יכול להיות מעניין אם כן 🙂

      לגבי שמירה אופליין של HTML5 – לא הכרתי, נשמע מעניין. מעיין הרחבה של קוקיז? כלומר JS יוכל לשמור BLOB של תוכן טופס בקוקי-צמוד-URL, אם הבנתי אותך? נשמע פתרון לא רע בכלל! אבל אני לא מכיר את הטכנולוגיה, אז אולי כדאי שתקפוץ לעמוד שלו ותציע את הרעיון במילים הנכונות.

  2. מדובר באחד הפיצ'רים המעניינים של HTML5, אם כי המימוש של פיירפוקס נותן רק גישה לנתונים במבנה של JSON, בעוד Google Gears מאפשר בנוסף גם גישה למסד נתונים מבוסס sqlite. האמת שאין את זה בפיירפוקס מהסיבה היחידה שהתקן המתגבש לא מציין מול איזה תקן SQL עובדים, וגוגל מימשו זאת מול תקן SQL לא מוכר בשם SQLite…

    הי, אני זוכר אותך מפעם שעברה! אני הייתי זה עם הקרחת והמשקפיים,
    ואני זוכר שביקשת שאשלח לך תגובות על השרשור הזה.

    (ואני מכחיש שיש לי קרחת. יש לי שיער דליל, אבל עדיין יש שם משהו)

    1. עדיין זה שעם הקרחת זה אני וזה שביקש דיווחים על תגובות הוא אתה… 🙂

      אני צריך להתחיל לפרסם שיעורים בהבנת הנקרא…

      SQlite "לא מוכר"? המון משתמשים בו, ראיתי אפילו אפליקציות ווביות שמשתמשות בו – האחרונות הן Gallery3 ואפילו הגרסא הבאה של מדיה־ויקי.

      1. sqlite זו תוכנה למסדי נתונים, בדיוק כמו mysql ו־mssql. המשותף לכל השלושה שציינתי ואחרות הוא התקן שהן מתבססות עליו, אבל כפי שאתה בוודאי יודע לכל מסד נתונים יש סט של פקודות משלו שמשפרות מאד את השפה הבסיסית.

        בתיאוריה אם נתבסס כולנו על אותו sql בסיסי לא יהיה לנו שום צורך בהתאמות מיוחדות כדי להתאים מערכת וובית לשיטה אחרת, אבל לא כך הדבר וכולם משתמשים בפקודות המתקדמות יותר (אם אני לא טועה, בשפה הבסיסית אין בכלל מבנה blob).

        תאר לך מצב בו כרומיום יממש מסד נתונים מסוג sqlite, בעוד פיירפוקס יתבסס על התקן – יהיה לנו פה מצב של חוסר תאימות בין דפדפנים זהה למה שהיה לנו לפני עשור, ומוזילה לא יסכימו שזה יקרה, למרות העובדה שפיירפוקס עצמו משתמש במנוע במסד נתונים sqlite ממש כמו כרומיום.

        בקשר להבנת הנקרא – כנראה ויש לי בעית הבנה קלה כשההתקנה של וורדפרס שלך חושבת שהיא יצור אנושי. 🙂

        1. מה אכפת לי מה התקן בbackend? הדרישות שלי הן שהפורמט יהיה יעיל, פתוח, שריד (יעמוד בקריסות תוכנה), יתמך על ידי יותר ממוצר אזוטרי בודד ולא יחריך את המתכנת שרוצה לגשת אליו להשתמש בAPI שונה.

          אם מה שאתה אומר מציע שהעבודה בJS שונה מול שני המנועים אז זו הבעיה האמיתית, מלבד הבעיה הזו, אני רואה מנסיוני האישי (לא קראתי על זה) שSQLite יותר שריד, משתמש בג'ורנל מסודר וככלל עושה רושם יותר רציני כמסד נתונים, ואילו JSON עדיף לו שישאר אולי כפורמט פורטאבילי של אחסון וגיבוי, אבל לא שליפה, וגם זה בעייתי כשיש מוסכמות XML יותר פשוטות.

          (שלחתי מהר מדי) בקיצור אם יש שכבת אבסטראקציה טובה ואחסון מוצלח, אין לי בעיה שתהיה תחרות, זה בריא.

          לגבי תוכנות עם אישיות – זה נושא שיעצבן אותך עוד יותר ויותר בעתיד, אז כדאי שתתחיל להתרגל 🙂
          וורדפרס חדשה מגיעה עם הודעה מ"גב' וורדפרס", ההודעה עם הקרחת זה מטעמי, בעל הבלוג…

          1. הפקודות של Javascript יהיו זהות, אבל התוכן של הפקודות עלול להיות שונה מאחר ואף־אחד לא קבע שמתבססים על סט הפקודות של מימוש כזה או אחר. אינטרנט אקספלורר, למשל, עשוי להשתמש במימוש של MS-SQL, ובכך לשבור תאימות מול דפדפנים אחרים, ואנחנו לא נרצה שזה יהיה כך.

            לגבי ההבדל בין JSON ל־Structured offline storage – ג'ימייל משתמשים ב־SQL בעוד WordPress משתמש ב־JSON (בגירסה 2.8 וורדפרס לא יחייב אותך להשתמש ב־Gears ויוכל לעבוד גם מול המימוש המובנה של הדפדפן). ההבדל פשוט – אי־אפשר לעשות שאילתות כל עוד אין לך DB, ואני לא חושב שהייתי רוצה לעבד בדפדפן כמה מגות טובות של נתונים בכל פעם שאני ניגש לתיבה שלי באופליין.

            בקשר לעוגיות, כן, המימוש דומה, אבל ההבדל הוא שלא שולחים לשרת כל פיסת מידע שהדפדפן יודע על האתר. טכנית אפשר לממש אפילו SSL בדפדפן…

            1. וממתי וורדפרס "מחייב" אותי להשתמש בגירז? חשבתי שהוא משתמש בו רק בשביל קאשינג מקומי של הרכיבים הגרפיים של המנשק ולא יותר מזה.

              "הפקודות של Javascript יהיו זהות, אבל התוכן של הפקודות עלול להיות שונה"

              אין לי מילים.

              מה הלאה? "מנשק התוכנה יהיה זהה אבל הAPI שונה?"

              כשאמרתי API תקני והשתמשתי ספציפית במילה "אבסטראקציה" התכוונתי שאותו הסקריפט ירוץ בלי שינויים, ושזו דרישה בסיסית! מה לא ברור?

  3. אני לא מבין למה וורדפרס מגביל את כמות התגובות לתגובות ולא דואג לתצוגה סבירה של הדיון בלי שהוא יראה קטוע. בכל מקרה, להלן תגובתי.

    וממתי וורדפרס "מחייב" אותי להשתמש בגירז? חשבתי שהוא משתמש בו רק בשביל קאשינג מקומי של הרכיבים הגרפיים של המנשק ולא יותר מזה.

    אני לא בטוח אם זה נכנס ב־2.7 או לא, אבל דובר על שימוש ב־HTML5 Offline Storage בשביל לתת לך גישה לטיוטות ולפוסטים שלך גם כאשר אתה לא מקוון.

    מה הלאה? "מנשק התוכנה יהיה זהה אבל הAPI שונה?"

    בדיוק. תדמיין שאותו אתר יכלול שני מימושים נפרדים בשביל להתאים לכל מסדי הנתונים הקיימים, ואז יבואו כל מיני פרוייקטים שיהוו wrapper בשביל לספק למפתח שכבת תאימות מול כל מסדי הנתונים, ויהיה שמח. זו הסיבה היחידה שמוזילה עצרו את ההטמעה של המפרט בפיירפוקס, לפחות עד שיהיה תקן אחיד שכל הדפדפנים יצטרכו לעבוד לפיו.

    1. [רמות תשובה]: כי באיזשהוא שלב, יותר מדי רמות תשובה בשיחה מוצגות לא טוב והופכות את השליפה ממסד הנתונים למאוד לא יעילה.

      [API שונה וזהה בו זמנית]: אז אתה מסכים איתי שאין כאן שום חתול חי ומת בו זמנית, ויש לך בעית ניסוח… אני אגיד את זה בפעם השלישית והאחרונה – אם הAPI זהה (או אם תרצה – יש wrapper אחיד), אז מה אכפת לי מה יש מתחת למעטפת, כל עוד הוא אמין, שריד ופתוח? כשאני אומר API אחיד אני מתכוון שלא צריך לכתוב גרסאות שונות של הקוד לHTML5 של דפדפנים שונים, וגוגל-גירז זה סיפור נפרד לגמרי.

  4. בעקרון יש עבודה על הרחבה אחרת לעורך WYSIWUG (מה שאת רואה זה מה שאת מקבלת) – זה אמור להיות לכל הדפדפנים – רק שלא הצלחתי להתקין את זה (דורש יכולת הרצת סקריפטים בשרת).
    לי נראה שזה דבר חשוב מאוד, ואשמח להתקין כזה דבר בויקים בהם אני עובד.

    זה לא בריא לכתוב טקטס במשך חצי שעה בלי לשמור. בטח לא בויקי.

    לקח לי זמן להבין חלק קטן מכל הקללות שעפו כאן.

    1. לא קללות…

      שמירות תכופות – התקן את lazarus או את WikiEditPuffer.

      עריכה משוכללת – התקן גריזמונקי ואז WikiEd.

      עריכת WYSIWYG לויקי זה לא סיפור מובן מאליו ולא ברור אם רצוי (לסיבות הצץ כאן), אבל התקנתי לי את FCKeditor באחד הויקים שלי ושיחקתי איתו קצת. לא משהו, אני חייב להגיד לך.

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *