התאמת האפליקציה לשוק המקומי

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

בדף הזה מתוארות שיטות מומלצות להתאמה לשוק המקומי של אפליקציות ל-Android.

אתם צריכים ידע מעשי ב-Kotlin והיכרות עם טעינת משאבים ב-Android, שיקולי פיתוח כמו מחזור החיים של פעילות ועקרונות כלליים של התאמה לשוק המקומי ולשפות ותרבויות שונות.

מומלץ להשתמש ב-Android resource framework כדי להפריד ככל האפשר בין ההיבטים של האפליקציה שעברו התאמה לשוק המקומי לבין תכונות האפליקציה.

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

המדריך הזה עוסק במערכת הלוקליזציה העיקרית של Android, שמשמשת בכל האפליקציות ל-Android. במאמר משאבים ב-Compose מוסבר איך לטעון את המשאבים המותאמים לשוק המקומי בממשק המשתמש של Jetpack Compose.

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

סקירה כללית: מעבר בין משאבים ב-Android

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

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

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

למה משאבי ברירת המחדל חשובים

כשהאפליקציה פועלת בלוקאל שלא סיפקתם לו טקסט ספציפי, Android טוענת את המחרוזות שמוגדרות כברירת מחדל מ-res/values/strings.xml. אם קובץ ברירת המחדל הזה לא קיים, או אם חסרה בו מחרוזת שהאפליקציה צריכה, האפליקציה לא תפעל ותוצג שגיאה. הדוגמה הבאה ממחישה מה יכול לקרות כשקובץ הטקסט שמוגדר כברירת מחדל לא מלא.

לדוגמה:

קוד מבוסס-Kotlin של אפליקציה מתייחס רק לשתי מחרוזות, text_a ו-text_b. האפליקציה כוללת קובץ משאבים מותאם לשוק המקומי (res/values-en/strings.xml) שמגדיר את text_a ו-text_b באנגלית. האפליקציה כוללת גם קובץ משאבים שמוגדר כברירת מחדל (res/values/strings.xml) שכולל הגדרה ל-text_a, אבל לא ל-text_b.

  • כשהאפליקציה הזו מופעלת במכשיר שהלוקאל שלו מוגדר לאנגלית, היא עשויה לפעול בלי בעיה כי res/values-en/strings.xml מכיל את שתי מחרוזות הטקסט הנדרשות.
  • אבל כשמפעילים את האפליקציה הזו במכשיר שמוגדר לשפה שאינה אנגלית, המשתמש רואה הודעת שגיאה וכפתור "סגירה כפויה". האפליקציה לא נטענת.

כדי למנוע את המצב הזה, ודאו שקיים קובץ res/values/strings.xml ושהוא מגדיר כל מחרוזת נדרשת. המצב הזה רלוונטי לכל סוגי המשאבים, לא רק למחרוזות: צריך ליצור קבוצה של קובצי משאבים שמוגדרים כברירת מחדל, שמכילים את כל המשאבים שהאפליקציה קוראת להם, כמו פריטים שניתן לשרטט, גופנים או צבעים. למידע על בדיקות, ראו את הקטע בדיקת משאבי ברירת המחדל.

שימוש במשאבים ללוקליזציה

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

יצירת משאבים שיוגדרו כברירת מחדל

מזינים את טקסט ברירת המחדל של האפליקציה ב-res/values/strings.xml. במחרוזות האלה, השתמשו בשפת ברירת המחדל – השפה שאתם מצפים שרוב המשתמשים באפליקציה ידברו בה.

קבוצת המשאבים שמוגדרת כברירת מחדל כוללת גם את כל רכיבי ה-drawable שמוגדרים כברירת מחדל, ויכולה לכלול סוגים אחרים של משאבים כמו סמלים או מחרוזות. המשאבים האלה נכנסים לספריות הבאות:

  • ‫res/drawable/: ספריית חובה שמכילה לפחות קובץ גרפי אחד, לסמל של האפליקציה ב-Google Play
  • ‫res/xml/: חובה אם יש לכם תיקיות res/xml-<qualifiers>
  • ‫res/raw/: חובה אם יש לכם תיקיות res/raw-<qualifiers>

יצירת משאבים חלופיים

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

אפליקציה יכולה לציין הרבה ספריות res/<qualifiers>/, לכל אחת מהן יש מגדירים שונים. כדי ליצור משאב חלופי לאזור אחר, משתמשים במאפיין שמציין שפה או שילוב של שפה ואזור. השם של ספריית המשאבים חייב להתאים לסכמת השמות שמתוארת במאמר הוספת משאבים חלופיים, אחרת לא תוכלו לקמפל את האפליקציה.

לדוגמה:

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

  1. res/values/strings.xml
    מכיל טקסט באנגלית לכל המחרוזות שבהן האפליקציה משתמשת, כולל טקסט למחרוזת בשם title.
  2. res/values-fr/strings.xml
    מכילים טקסט בצרפתית לכל המחרוזות, כולל title.
  3. res/values-ja/strings.xml
    מכיל טקסט ביפנית לכל המחרוזות חוץ מ title.

אם הקוד שלכם שמבוסס על Kotlin מתייחס ל-R.string.title, זה מה שקורה בזמן הריצה:

  • אם המכשיר מוגדר לשפה אחרת, Android טוען את title מהקובץ res/values/strings.xml.
  • אם המכשיר מוגדר לצרפתית, Android טוען את title מהקובץ res/values-fr/strings.xml.

אם המכשיר מוגדר ליפנית, Android מחפש את title בקובץ res/values-ja/strings.xml. אבל מכיוון שהקובץ הזה לא כולל מחרוזת כזו, Android חוזרת לברירת המחדל וטוענת את title באנגלית מהקובץ res/values/strings.xml.

לאילו משאבים יש קדימות?

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

לדוגמה:

נניח שאפליקציה כוללת קבוצת גרפיקה שמוגדרת כברירת מחדל ושתי קבוצות גרפיקה אחרות, שכל אחת מהן מותאמת להגדרת מכשיר אחרת:

  • res/drawable/
    מכיל גרפיקה שמוגדרת כברירת מחדל.
  • res/drawable-small-land-stylus/
    מכיל גרפיקה שעברה אופטימיזציה לשימוש במכשיר שמצפה לקלט מחרט ויש לו מסך QVGA עם צפיפות פיקסלים נמוכה בכיוון לרוחב.
  • res/drawable-ja/
    מכיל גרפיקה שמותאמת לשימוש ביפנית.

אם האפליקציה פועלת במכשיר שמוגדר לשימוש ביפנית, Android טוענת גרפיקה מ-res/drawable-ja/, גם אם המכשיר מצפה לקלט מחרט ויש לו מסך QVGA עם צפיפות פיקסלים נמוכה בכיוון לרוחב.

חריג: המאפיינים היחידים שקודמים ללוקאל בתהליך הבחירה הם קוד המדינה של הרשת הסלולרית (MCC) וקוד הרשת הסלולרית (MNC).

לדוגמה:

נניח שזה המצב:

  • קוד האפליקציה קורא ל-R.string.text_a.
  • יש שני קובצי משאבים רלוונטיים:
    • ‫res/values-mcc404/strings.xml, שכולל את text_a בשפת ברירת המחדל של האפליקציה, במקרה הזה אנגלית.
    • ‫res/values-hi/strings.xml, שכולל את text_a בהינדית.
  • האפליקציה פועלת במכשיר עם ההגדרות הבאות:
    • כרטיס ה-SIM מחובר לרשת סלולרית בהודו (MCC 404).
    • השפה מוגדרת להינדי (hi).

מערכת Android טוענת את text_a מ-res/values-mcc404/strings.xml (באנגלית), גם אם המכשיר מוגדר להינדי. הסיבה לכך היא שבתהליך בחירת המשאבים, Android מעדיפה התאמה של MCC על פני התאמה של שפה.

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

הפניה למשאבים בקוד

בקוד של האפליקציה שמבוסס על Kotlin, מפנים למשאבים באמצעות התחביר R.resource_type.resource_name או android.R.resource_type.resource_name. מידע נוסף זמין במאמר גישה למשאבי האפליקציה.

ניהול מחרוזות ללוקליזציה

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

העברת כל המחרוזות לקובץ strings.xml

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

לדוגמה, באמצעות Compose, אפשר לטעון מחרוזת כזו:

// In the res/values/strings.xml file
// <string name="compose">Jetpack Compose</string>

// In your Compose code
Text(
    text = stringResource(R.string.compose)
)

אם יוצרים תמונות מ-AI עם טקסט, צריך להוסיף את המחרוזות האלה גם ל-strings.xml, וליצור מחדש את התמונות אחרי התרגום.

פועלים לפי ההנחיות של Android לגבי מחרוזות של ממשק משתמש

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

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

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

לספק מספיק הקשר למחרוזות המוצהרות

כשמצהירים על מחרוזות בקובץ strings.xml, חשוב לתאר את ההקשר שבו משתמשים במחרוזת. המידע הזה חשוב מאוד למתרגם, והוא עוזר לשפר את איכות התרגום. הוא גם עוזר לכם לנהל את המחרוזות בצורה יעילה יותר.

לדוגמה:

<!-- The action for submitting a form. This text is on a button that can fit 30 chars -->
<string name="login_submit_button">Sign in</string>

כדאי לספק מידע על ההקשר, למשל:

  • למה משמשת המחרוזת הזו? מתי ואיפה הוא מוצג למשתמש?
  • איפה זה נמצא בממשק המשתמש? לדוגמה, התרגומים פחות גמישים בלחצנים מאשר בתיבות טקסט.

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

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

כדי לסמן טקסט שלא צריך לתרגם, משתמשים בתג פלייסהולדר <xliff:g>. הנה דוגמה לתג שמציין שאין לשנות את הטקסט "%1$s" במהלך התרגום, כדי למנוע שיבוש של ההודעה:

<string name="countdown">
  <xliff:g id="time" example="5 days">%1$s</xliff:g> until holiday
</string>

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

הנה עוד כמה דוגמאות לתגי פלייסהולדר:

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<!-- Example placeholder for a special Unicode symbol -->
<string name="star_rating">Check out our 5
    <xliff:g id="star">\u2605</xliff:g>
</string>
<!-- Example placeholder for a URL -->
<string name="app_homeurl">
    Visit us at <xliff:g
    id="application_homepage">http://my/app/home.html</xliff:g>
</string>
<!-- Example placeholder for a name -->
<string name="prod_name">
    Learn more at <xliff:g id="prod_gamegroup">Game Group</xliff:g>
</string>
<!-- Example placeholder for a literal -->
<string name="promo_message">
    Please use the "<xliff:g id="promotion_code">ABCDEFG</xliff:g>" to get a discount.
</string>
...
</resources>

רשימת משימות להתאמה לשוק המקומי

במאמר תרגום והתאמה לשוק המקומי של האפליקציה מוסבר בהרחבה איך מתאימים אפליקציה ל-Android לשוק המקומי ומפיצים אותה.

טיפים להתאמה לשוק המקומי

הטיפים הבאים יעזרו לכם להתאים את האפליקציה לשוק המקומי.

עיצוב האפליקציה כך שתפעל בכל לוקאל

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

חשוב: ודאו שהאפליקציה כוללת קבוצה מלאה של משאבי ברירת מחדל: כללו תיקיות res/drawable/ ו-res/values/ ללא משתנים נוספים בשמות התיקיות, שמכילות את כל התמונות והטקסט שהאפליקציה צריכה.

אם באפליקציה חסר אפילו משאב אחד שמוגדר כברירת מחדל, היא לא תפעל במכשיר שמוגדרת בו שפה או אזור שלא נתמכים. לדוגמה, אם בקובץ ברירת המחדל res/values/strings.xml חסרה מחרוזת אחת שהאפליקציה צריכה, כשהאפליקציה פועלת בלוקאל לא נתמך ומנסה לטעון את res/values/strings.xml, המשתמש רואה הודעת שגיאה ולחצן "סגירה כפויה".

מידע נוסף זמין בקטע בדיקת משאבי ברירת המחדל.

הימנעו מיצירת יותר קובצי משאבים ומחרוזות טקסט ממה שאתם צריכים

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

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

  • שפת ברירת המחדל של האפליקציה היא אנגלית אמריקאית. כל מחרוזת שהאפליקציה משתמשת בה מוגדרת בקובץ res/values/strings.xml, באיות של אנגלית אמריקאית.
  • אתם רוצים לספק איות באנגלית בריטית לכמה ביטויים חשובים. אתם רוצים שהמחרוזות החלופיות האלה ישמשו כשהאפליקציה פועלת במכשיר בבריטניה.

כדי לעשות את זה, יוצרים קובץ קטן בשם res/values-en-rGB/strings.xml שכולל רק את המחרוזות ששונות כשהאפליקציה פועלת בבריטניה. בשאר המחרוזות, האפליקציה חוזרת לברירות המחדל ומשתמשת במה שמוגדר בקובץ res/values/strings.xml.

שימוש ב-LocalConfiguration לחיפוש ידני של לוקאל

אפשר לחפש את הלוקאל באמצעות LocalConfiguration שזמין ב-Android, כמו בדוגמה הבאה:

val locale = LocalConfiguration.current.locales[0]

שימוש בשירותים לתרגום אפליקציות

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

איך משתמשים ב-Gemini כדי לתרגם מחרוזות של אפליקציות

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

בדיקת אפליקציות שעברו לוקליזציה

בודקים את האפליקציה המותאמת לשוק המקומי במכשיר או באמצעות אמולטור Android. במיוחד, בדקו את האפליקציה כדי לוודא שכל משאבי ברירת המחדל הדרושים כלולים.

בדיקה במכשיר

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

כדי לשנות את הלוקאל או השפה במכשיר, משתמשים באפליקציית ההגדרות.

בדיקה באמצעות תצוגות מקדימות של רכיבים קומפוזביליים

לפני הבדיקה במכשיר, אתם יכולים להשתמש בתצוגות מקדימות של פונקציות קומפוזביליות ב-Android Studio כדי לבדוק ממשקי משתמש מותאמים לשוק המקומי בלי לפרוס אותם באמולטור. כדי לראות תצוגה מקדימה של ממשק המשתמש בשפות שונות, משתמשים בהערה @Preview (כמו @Preview(locale = "fr")). אפשר גם לבדוק פריסות מימין לשמאל (RTL) על ידי ציון לוקאל RTL כמו @Preview(locale = "ar").

בדיקה באמולטור

למידע נוסף על השימוש באמולטור, ראו הפעלת אפליקציות באמולטור Android.

יצירה ושימוש בלוקאל בהתאמה אישית

הגדרות "מותאמות אישית" של מיקום הן שילוב של שפה או אזור שאין להם תמיכה מפורשת בקובץ האימג' של מערכת Android. כדי לבדוק איך האפליקציה פועלת בלוקאל מותאם אישית, אתם יכולים ליצור לוקאל מותאם אישית באמולטור. יש שתי דרכים לעשות את זה:

  • משתמשים באפליקציה Custom Locale, שאפשר לגשת אליה מכרטיסיית האפליקציות. אחרי שיוצרים לוקאל בהתאמה אישית, אפשר לעבור אליו בלחיצה ארוכה על שם הלוקאל.
  • שינוי ללוקאל בהתאמה אישית ממעטפת adb, כמו שמתואר בקטע הבא.

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

שינוי הלוקאל של האמולטור ממעטפת adb

כדי לשנות את הלוקאל באמולטור באמצעות המעטפת של adb:

  1. בוחרים את הלוקאל שרוצים לבדוק וקובעים את תג השפה שלו לפי תקן BCP-47, למשל fr-CA לצרפתית קנדית.
  2. מפעילים אמולטור.
  3. ממעטפת שורת הפקודה במחשב המארח, מריצים את הפקודה הבאה:
    adb shell
    או, אם יש מכשיר מחובר, מציינים שרוצים את האמולטור על ידי הוספת האפשרות -e:
    adb -e shell
  4. בשורת הפקודה של adb (#), מריצים את הפקודה הבאה:
    setprop persist.sys.locale [BCP-47 language tag];stop;sleep 5;start
    מחליפים את החלקים שבסוגריים בקודים המתאימים משלב 1.

    לדוגמה, כדי לבדוק בצרפתית קנדית:
    setprop persist.sys.locale fr-CA;stop;sleep 5;start

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

בדיקת משאבי ברירת המחדל

כדי לבדוק אם האפליקציה כוללת את כל משאבי המחרוזות שהיא צריכה, מבצעים את הפעולות הבאות:

  1. מגדירים את האמולטור או המכשיר לשפה שהאפליקציה לא תומכת בה. לדוגמה, אם לאפליקציה יש מחרוזות בצרפתית ב-res/values-fr/ אבל אין לה מחרוזות בספרדית ב-res/values-es/, מגדירים את הלוקאל של האמולטור לספרדית. אתם יכולים להשתמש באפליקציה Custom Locale כדי להגדיר את האמולטור ללוקאל שלא נתמך.
  2. מפעילים את האפליקציה.
  3. אם באפליקציה מוצגת הודעת שגיאה והלחצן "סגירה ידנית", יכול להיות שהיא מחפשת מחרוזת שלא זמינה. חשוב לוודא שהקובץ res/values/strings.xml כולל הגדרה לכל מחרוזת שבה האפליקציה משתמשת.

אם הבדיקה מצליחה, חוזרים עליה עם סוגים אחרים של הגדרות אישיות. לדוגמה, אם לאפליקציה יש קובץ מחרוזת בשם res/values-land/strings.xml אבל אין לה קובץ בשם res/values-port/strings.xml, צריך להגדיר את האמולטור או המכשיר לכיוון לאורך ולבדוק אם האפליקציה פועלת.

מקורות מידע נוספים

למידע נוסף על לוקליזציה, אפשר לעיין במקורות המידע הבאים:

תיעוד

צפייה בתוכן

הבא
Test your app with pseudolocales