The N.Z.B

הפעם האחרונה שתוסף ה Wp-polls תורגם לעברית היה אצל דקר לפני כמעט שנתיים.מאז, התוסף התפתח והתעדכן ועם הזמן, התווספה עבורו תמיכה בתרגום בעזרת קבצי תרגום (mo/po). היתרון בקבצי התרגום הללו הוא שהם מאפשרים להפריד בין התרגום לבין הקוד עצמו ובכך מבטלים את הצורך של המתרגם לעבור מחדש על התוסף בכל פעם שהוא מתעדכן.

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

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

Popularity: 6% [?]

אני חייב לציין שתוספת התגיות בוורדפרס הצליחה לבלבל אותי קלות. בהתחלה, היו לי רק קטגוריות, זה היה מאוד פשוט בהתחלה שכן כל נושא קיבל קטגוריה משל עצמו ובשלב מסויים, כאשר הצטברה מסה של נושאים כל פוסט חדש שוייך לרשימת הנושאים הרלוונטים עבורו. עם הזמן הרשימה התארכה והוחלפה מרשימה אורכית ל"ענן תגיות" אך עדיין אלו היו קטגוריות הן רק סודרו בצורה אחרת.
ואז הגיע וורדפרס 2.3 ואיתו גם התמיכה בתגיות בנוסף לתמיכה בקטגוריות. לורל כתבה פעם שתגיות הן לא קטגוריות ואני אפילו מוכן לקבל את זה במערכות גדולות מספיק, אבל האם זה באמת משנה עבור בלוג קטן?

חלוקה הגיונית עבור אתר גדול לצורך העיניין הייתה יכולה להיות קטגורית מחשבים ומתחתיה תתי קטגוריות של ניידים, נייחים ומחשבי כף יד. בתור תגיות ניתן היה להשתמש בשמות היצרנים כגון HP, IBM, LG וכ. כך ניתן לצפות בקלות על כל המחשבים הניידים או על כל המוצרים של LG וזו אכן תהייה חלוקה הגיונית ונוחה למשתמש (לדעתי לפחות, אתם מוזמנים לחלוק עליה).
באתר חברתי לעומת זאת, החשיבות של קטגוריות מתבטלת כמעט לחלוטין, אבל השימוש בתגיות נהפך לדומיננטי. ככה למשל הדבר הכי קרוב לקטגוריות בפליקר הוא הסטים והוא אישי לכל גולש, בעוד שהתגיות מאפשרות בקלות לצפות בכל התוכן של כל הגולשים שתייגו תמונות במילה הספציפית הזו. ע"י חיפוש התגית Rain ניתן למצוא את כל התגיות שבעליהן חשבו שהן קשורות לגשם.

בניגוד לאתרי תוכן גדולים או לרשתות חברתיות הרי שוורדפרס היא מערכת תוכן עבור אתרים קטנים שנועדה במקור לניהול של בלוגים. נכון שניתן להסב אותה ללא מעט שימושים אחרים, כולל כבסיס לאתרי תוכן גדולים, אך במקור, מדובר בפלטפורמה לבלוג וההפרדה כאן בין תגיות לקטגוריות היא מאולצת וקצת קשה לי לעכל אותה.
אז הנה כתבתי פוסט והוא קשור לאינטרנט ולוורדפרס ובגלל שיש לי את הקטגוריות הרלוונטיות, אני משייך את הפוסט הזה לשתי הקטגוריות הללו. והנה השאלה - מה אני אמור לכתוב בשורת התגיות? יתר על כן, אל מה יקשרו אותן התגיות? שדה התגיות הוא שדה טקסט חופשי ובסופו של דבר מי שכותב על נושאים רחבים מספיק יכול לייצר רשימת תגיות ארוכה מספיק עם מעט מאוד נושאים עבור כל תגית. למעשה, זה לא שונה מרשימת הקטגוריות הארוכה שלי שיש בה קטגוריות בעלות 70 פוסטים ולעומתן קטגוריות בעלות 2 פוסטים.

בעבר חשבתי להשתמש בתגיות כמילות מפתח בתגית המטא בהדר. כך, ניתן לשתול בהדר של כל עמוד את כל התגיות הרלוונטיות עבורו. עם זאת, היות והמילים הללו גם ככה מופיעות בעמוד, במיוחד אם מציגים בתחתית כל פוסט את התגיות הקשורות לו הרי שמנועי החיפוש יאנדקסו את העמודים הללו עבור המילים הללו בכל מקרה.
אני מניח ששאלת המפתח, והיא שאלה שמאוד מטרידה אותי בגלל הרצון שלי לעבור לערכת עיצוב חדשה, היא איך עוברים מ 67 קטגוריות לא יעילות ל 4-6 קטגוריות יעילות ומתייגים את יתר הפוסטים נכונה. איך נמנעים ממצב שבו בעוד שנה יש רשימת תגיות באורך הגלות אבל שאין לה כל רלוונטיות או במילים אחרות - איך אוכלים את המכה הזו שנקראת תגיות.

Popularity: 14% [?]

ההתלהבות המופגנת מהאפשרות לשתף סימניות עם הערות בגוגל רידר היא ברורה ומובנת אבל היא מהווה הסחת דעת מעוול נוראי!

עד היום, ישב לו בנחת בתחתית כל פוסט בגוגלרידר צ'ק בוקס שנשא את הכיתוב Read. הרעיון היה פשוט מאוד - אם קראת את הפוסט סומן בו V, פוסטים שעוד לא קראת, לא סומנו ב V. זה איפשר למי שהוסיף פיד חדש ורצה לסמן במהירות מספר פוסטים ישנים כפוסטים שנקראו, לסמן אותם ככאלה ללא שום בעיה.

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

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

יוחזר ה READ לאלתר!

Popularity: 12% [?]

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

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

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

Popularity: 9% [?]

לפני זמן לא רב, מת מסך ה LCD הוותיק שלי והוא בן שלוש שנים וחודש. בדיוק חודש לאחר פקיעת האחריות בת שלוש השנים הוא החזיר את פיקסליו למקום שבו נחים הפיקסלים השרופים. אלפיה שהונחה אצל הקופאית ברשת שופרסל דיל זיכתה אותי במסך Benq חדש בעל מסך רחב ואלכסון של 20". 1680 פיקסלים לרוחב, 1050 פיקסלים לגובה זו הגדרת הרזולוציה שלי וכאן בדיוק מתחילה הבעיה או הדילמה.
רוחבו של העיצוב הנוכחי שלי הוא 780 פיקסלים ורוחבה של עמודת הטקסט עצמה הוא כמעט 500 פיקסלים ובמסך ברזולוציה של 800 פיקסלים לרוחב זה יושב בול. מצד שני, הפעם האחרונה שהשתמשתי ברזולוציה של 800×600 זה היה כשניסיתי לשחזר מחשב ישן בעזרת מסך 14 אינט'ש ישן שמצאתי במחסן. עם זאת, הגוגל אנליטיקס מתעקש (עד כמה שניתן להאמין לו) שלכ 7% מהמבקרים בבלוג אכן יש רזולוצית מסך של 800X600. על להגדיל חשבתי כבר בעבר אבל כשעבדתי על 17" השתמשתי ברזולוציה של 1280X1024 שגם אם היא משמשת כ 22% ממבקרי הבלוג עדיין היא לא רזולוציה טבעית. רוב המשתמשים מעדיפים, כך נראה, רזולוציה של 1024X800 וזה רק מגדיל את הדילמה.

עיצוב בעזרת CSS מאפשר שני סוגים עיקריים של עיצוב - קבוע ויחסי. עבור כל אובייקט שמקבל גדלים כפרמטר ניתן להשתמש בשני סימונים עיקריים - px (מייצג פיקסלים) או % (אחוזים). כך למשל, אם נרצה להגדיר תיבה שהרוחב שלה הוא 20 פיקסלים נשתמש בהגדרה: width: 20px.
הרעיון מאחורי העיצוב הקבוע אומר שהמעצב מגדיר מידות אחידות עבור כל רכיב באתר וככה הוא יוצג בכל הדפדפנים (ונניח לתאימות קוד ושונות דפדפנים בצד כרגע). זה מאפשר לבעל האתר לדאוג שהאתר שלו יראה זהה הן ברזולוציות נמוכות והן ברזולוציות גבוהות. אבל, על נוחות וודאות צריך לשלם וזה קורה בעיצוב קבוע בכמה נקודות:
א. הביזבוז.
אם האתר נבנה עבור רוחב של 800 פיקסלים, הרי שברוחב של 1280 פיקסלים יש כ 480 פיקסלים "מבוזבזים" במקרה הטוב זה יציג שוליים, במקרה הרע זה ימרח את הטמפלט בצורה מזוויעה. השימוש בבר צידי ושאר ריווחים גוזרים גם הם קופון נאה מהרוחב הכללי ולבסוף נשארים כאמור עם פחות מ 500 פיקסלים עבור הכתיבה. (שזה לא חריג. נענע משתמשים ב 500 , ynet בכ 430 ו NRG בכ 450).
ב. גמישות
השימוש ב Float על מנת לייצר שני אובייקטים זה לצד זה הוא נפוץ למדי. הבעיה היא, שאובייקט Float שמוגדר בגודל קבוע לא מסוגל להצטמצם. במילים אחרות, עיצוב שהותאם ל 1024 ישבר לחלוטין ב 800, אם כי אפשר לרתום את התכונה הזו על מנת לייצר אתר שמתאים לשני הרוחבים. מי שניסה לכווץ פעם חלון בוודאי ראה כיצד האובייקטים נדחסים עד השלב שבו הם מתחילים "ליפול" מהסדר שלהם.

העיצוב היחסי הוא הרבה יותר גמיש בעבור שתי הבעיות הללו. בשיטת העיצוב הזו מגדירים את רוחב כל תיבה ביחס למאת האחוזים המרכיבים את התיבה המכילה אותה. כך למשל, אם נגדיר את רוחב התיבה הראשית של הבלוג כ 90%, הרי שברוחב מסך של 800 פיקסלים נקבל עמודה בת 720 פיקסלים ואילו ברוחב של 1280 נקבל עמודה בת 1152 פיקסלים. בשני המקרים יתקבלו שוליים מינימליים (10% מרוחב המסך במקרה הלז) ויותר אזור יהיה זמין עבור התוכן. ככל שרוחב המסך יגדל ניתן יהיה לפרוס את הבלוג בצורה נוחה יותר, מרווחת יותר ומכאן שגם קריאה יותר. גם במקרה של הקטנת חלון או שינוי רזולוציה האובייקטים תמיד יסתדרו בגודל המתאים וישארו באותה הפרופורציה כך ששינוי גודל המסך לא ישנה את הסידור של האתר אלא רק את כמות התוכן המוצגת.
אבל, כמו בשיטה הקודמת, גם כאן יש מחירים
א. תמונות
בעיצוב הנוכחי, התמונות שלי הן אובייקט Float ברוחב 200 פיקסלים עם הצמדה לצד שמאל. זה מאפשר להכניס תמונות קטנות בצד של הפוסט וזה לא רע בכלל רוב הזמן, אבל לפעמים רוצים להכניס צילום מסך של אתר כזה או אחר צריך להקטין תמונה מ 800 פיקסלים ל 200 פיקסלים - מדובר פה בכיווץ לרבע מהגודל ובתהליך הזה הרבה מאוד פרטים הולכים לאיבוד. ואז חשבתי על האפשרות של תמונה לרוחב הפוסט (רוחב מלא, של כל עמודת הטקסט) אבל לבצע דבר שכזה בעיצוב יחסי זו משימה מאוד בעייתית. אם מגדירים את רוחב התמונה כ 100% הרי שעבור מסכים רחבים במיוחד התמונה תעבור תהליך מתיחה שיפגע בה, אם משתמשים בתמונה ברוחב מקסימלי, הרי שברוחב המינימלי התמונה תידחס ושוב תאבד מאיכותה, שלא לדבר על המשקלים של תמונות גדולות. האפשרות החלופית היא להשתמש בהגדרת רוחב קבועה, אז אומנם יודעים בדיוק מה יהיה רוחב התמונה אבל מצד שני כאן אפשר לפספס בשני הכיוונים - תמונה שגולשת מהשוליים או לחילופין כזו שיושבת באמצע הפוסט עם שוליים רחבים בכל צד - תקועה שכזו. אפשר אומנם לאלתר בעזרת פרמטרים כגון max-width ו min-width שיכולים להכריח רוחב מקסימלי ומינימלי, אבל זה עדיין מכוער. יתר על כן, בלוגים שיש להם גרפיקה בהדר עלולים להסתבך עוד יותר בגלל העיוות של המתיחה או הכיווץ.

ב. חישובים
אם רוחב המסך הוא 100% והתיבה הראשית היא 98% ובתוכה יש שלוש עמודות שכל אחת ברוחב של 32% עם ריווח של 1% מכל צד של כל עמודה, מה יהיה רוחב העמודה ברוחב מסך של 1280 פיקסלים? מה יהיה הסידור האופטימלי לחמש עמודות ברוחב שווה? או לארבע עמודות כאשר האמצעית רחבה פי 2 משלושת העמודות האחרות? בקיצור, אם בעיצוב הקבוע צריך לעבוד עם סרגל, הרי שבעיצוב היחסי צריך לעבוד עם מחשבון. זה עוד יחסית פשוט כאשר מייצרים ערכת עיצוב חדשה, אבל מה עושים כאשר מנסים לתרגם ערכת עיצוב מאנגלית תוך כדי החלפת סדר העמודות? בקיצור, עיצוב יחסי הוא כאב ראש בתחום הזה שכן הוא דורש מעקב צפוף לכל אורך ה CSS. שינוי הכי קטן במרכיב אחד מבלי לטפל במרכיבים הצמודים לו יכול להרוס את כל העיצוב.

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

Popularity: 11% [?]