Django అనువాదాలు ఎందుకు విఫలమవుతాయి (మరియు 10 సాధారణ కారణాలను ఎలా పరిష్కరించాలి)

మీరు అనువాదం కోసం స్ట్రింగ్‌లను గుర్తించారు, .po ఫైల్‌లను జనరేట్ చేశారు, compilemessages రన్ చేశారు, మరియు మీ యాప్ ఇంకా ఇంగ్లీష్‌లో చూపిస్తోంది. మీరు ఒంటరిగా లేరు. Django యొక్క i18n ఫ్రేమ్‌వర్క్ శక్తివంతమైనది, కానీ అనుభవజ్ఞులైన డెవలపర్లను కూడా పట్టుకునే పదునైన అంచులు ఉన్నాయి.

ఈ గైడ్ Django అనువాదాలు నిశ్శబ్దంగా విఫలమయ్యే 10 అత్యంత సాధారణ కారణాలను, ఒక్కొక్కదానికి ఖచ్చితమైన లక్షణాలు మరియు పరిష్కారాలతో కవర్ చేస్తుంది.

1. .po ఫైల్‌లను ఎడిట్ చేసిన తర్వాత compilemessages రన్ చేయడం మర్చిపోవడం

మీరు ఒక .po ఫైల్‌ను ఎడిట్ చేశారు (మాన్యువల్‌గా లేదా టూల్‌తో), కానీ అనువదించిన టెక్స్ట్ ఎప్పుడూ కనిపించదు. యాప్ అసలు ఇంగ్లీష్ స్ట్రింగ్‌లను చూపిస్తూనే ఉంటుంది.

Django రన్‌టైమ్‌లో .po ఫైల్‌లను చదవదు. బదులుగా కంపైల్ చేసిన .mo (మెషిన్ ఆబ్జెక్ట్) బైనరీ ఫైల్‌లను చదువుతుంది. మీరు .po ఫైల్‌ను రీకంపైల్ చేయకుండా ఎడిట్ చేస్తే, ఏదైనా మారిందని Django కు తెలియదు.

ప్రతి .po ఫైల్ మార్పు తర్వాత compilemessages రన్ చేయండి:

python manage.py compilemessages

మీరు TranslateBot తో మీ అనువాదాలను ఆటోమేట్ చేస్తే, మీ వర్క్‌ఫ్లో చివరి స్టెప్‌గా compilemessages జోడించండి:

python manage.py makemessages -a --no-obsolete
python manage.py translate
python manage.py compilemessages

2. టెంప్లేట్‌లలో {% load i18n %} లేదు

మీరు టెంప్లేట్‌లో {% trans "Hello" %} ఉపయోగిస్తున్నారు, కానీ Django TemplateSyntaxError ఇస్తుంది. లేదా అధ్వాన్నంగా, మీ టెంప్లేట్ ఇంజిన్ తప్పుగా కాన్ఫిగర్ చేయబడి ఉంటే ట్యాగ్ నిశ్శబ్దంగా ఏమీ చేయదు.

{% trans %} మరియు {% blocktrans %} ట్యాగ్‌లు Django యొక్క i18n టెంప్లేట్ ట్యాగ్ లైబ్రరీలో ఉంటాయి. దాన్ని లోడ్ చేయకుండా, టెంప్లేట్ ఇంజిన్ వాటిని గుర్తించదు.

అనువాద ట్యాగ్‌లను ఉపయోగించే ప్రతి టెంప్లేట్ పైభాగంలో {% load i18n %} జోడించండి:

{% load i18n %}

<h1>{% trans "Welcome to our site" %}</h1>
<p>{% blocktrans with name=user.name %}Hello, {{ name }}!{% endblocktrans %}</p>

ఇది ప్రతి-టెంప్లేట్ అవసరం. పేరెంట్ టెంప్లేట్ i18n లోడ్ చేసినప్పటికీ, అనువాద ట్యాగ్‌లను ఉపయోగించే చైల్డ్ టెంప్లేట్‌లకు వారి స్వంత {% load i18n %} డిక్లరేషన్ అవసరం.

3. LocaleMiddleware MIDDLEWARE లో లేదు లేదా తప్పు స్థానంలో ఉంది

బ్రౌజర్ యొక్క Accept-Language హెడర్, URL ప్రిఫిక్స్, లేదా సెషన్ సెట్టింగ్‌లతో సంబంధం లేకుండా Django ఎల్లప్పుడూ డిఫాల్ట్ భాషలో కంటెంట్ అందిస్తుంది.

LocaleMiddleware ప్రతి రిక్వెస్ట్ కోసం యాక్టివ్ భాషను నిర్ణయిస్తుంది. అది లేకుండా, Django LANGUAGE_CODE కు డిఫాల్ట్ అవుతుంది మరియు అన్ని భాష-ఎంపిక మెకానిజమ్‌లను విస్మరిస్తుంది. మిడిల్‌వేర్ స్టాక్‌లో దాని స్థానం కూడా ముఖ్యం, ఎందుకంటే దానికి సెషన్ డేటా మరియు URL రిజల్యూషన్ యాక్సెస్ అవసరం.

SessionMiddleware మరియు CommonMiddleware తర్వాత మీ MIDDLEWARE సెట్టింగ్‌కు LocaleMiddleware జోడించండి:

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.locale.LocaleMiddleware",  # Must be after SessionMiddleware
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
]

మీరు URL-ఆధారిత భాష స్విచింగ్ ఉపయోగిస్తే మీ URL కాన్ఫిగరేషన్‌లో django.conf.urls.i18n చేర్చబడిందని నిర్ధారించుకోండి:

from django.conf.urls.i18n import i18n_patterns

urlpatterns = i18n_patterns(
    path("", include("myapp.urls")),
)

4. భాష కోడ్ అసమతుల్యత (ఉదా. pt-br vs pt_BR)

అనువాదాలు మీ .po ఫైల్‌లలో ఉన్నాయి, compilemessages విజయవంతమవుతుంది, కానీ Django నిర్దిష్ట లొకేల్‌ల కోసం అనువాదాన్ని విస్మరిస్తుంది.

Django లొకేల్ డైరెక్టరీలు <language>_<COUNTRY> ఫార్మాట్‌ను అనుసరించాలని ఆశిస్తుంది, అండర్‌స్కోర్ సెపరేటర్ మరియు అప్పర్‌కేస్ కంట్రీ కోడ్‌తో. ఉదాహరణకు, బ్రెజిలియన్ పోర్చుగీస్ కోసం pt_BR. మీ డైరెక్టరీ pt-br, pt-BR, లేదా ptBR అని పేరు పెట్టబడి ఉంటే, Django దాన్ని కనుగొనదు. LANGUAGES సెట్టింగ్‌కు కూడా ఇదే వర్తిస్తుంది: అక్కడ కోడ్‌లు హైఫన్‌లు (pt-br) ఉపయోగిస్తాయి, కానీ ఫైల్‌సిస్టమ్ అండర్‌స్కోర్‌లు (pt_BR) ఉపయోగిస్తుంది.

మీ డైరెక్టరీ నిర్మాణం Django యొక్క అంచనాలకు సరిపోతుందని నిర్ధారించుకోండి:

locale/
    pt_BR/
        LC_MESSAGES/
            django.po
            django.mo

మరియు మీ సెట్టింగ్‌లలో, హైఫనేటెడ్ ఫారమ్ ఉపయోగించండి:

LANGUAGES = [
    ("en", "English"),
    ("pt-br", "Brazilian Portuguese"),
    ("zh-hans", "Simplified Chinese"),
]

makemessages రన్ చేసేటప్పుడు, లొకేల్ ఫ్లాగ్ కోసం అండర్‌స్కోర్ ఫారమ్ ఉపయోగించండి:

python manage.py makemessages -l pt_BR

5. కంపైలేషన్ సమయంలో Fuzzy ఎంట్రీలు నిశ్శబ్దంగా దాటవేయబడతాయి

.po ఫైల్‌లో అనువాదం ఉంది, కానీ Django ఆ నిర్దిష్ట ఎంట్రీ కోసం రన్‌టైమ్‌లో అసలు ఇంగ్లీష్ స్ట్రింగ్ చూపిస్తుంది. ఫైల్‌లో అనువాదం ఉన్నందున ఇది ప్రత్యేకంగా నిరాశపరుస్తుంది.

Django యొక్క makemessages సోర్స్ స్ట్రింగ్ కొద్దిగా మారిందని గుర్తించినప్పుడు, ఇది ఇప్పటికే ఉన్న అనువాదాన్ని "fuzzy" (మానవ సమీక్ష అవసరమైన అంచనా అని అర్థం) గా గుర్తిస్తుంది. compilemessages కమాండ్ అన్ని fuzzy ఎంట్రీలను దాటవేస్తుంది, వాటిని అనువదించనివిగా పరిగణిస్తుంది. కాబట్టి ఎంట్రీ .po ఫైల్‌లో అనువదించినట్లు కనిపిస్తుంది, కానీ .mo ఫైల్ దాన్ని పూర్తిగా మినహాయిస్తుంది.

fuzzy ఎంట్రీ ఇలా కనిపిస్తుంది:

#, fuzzy
msgid "Welcome to our website!"
msgstr "Welkom op onze website!"

అనువాదాన్ని సమీక్షించండి, అవసరమైతే msgstr అప్‌డేట్ చేయండి, ఆపై #, fuzzy ఫ్లాగ్ తొలగించండి:

msgid "Welcome to our website!"
msgstr "Welkom op onze website!"

ఆపై రీకంపైల్ చేయండి:

python manage.py compilemessages

పెద్ద ప్రాజెక్ట్‌లో, fuzzy ఎంట్రీలు పేరుకుపోతాయి మరియు మిస్ చేయడం సులభం. TranslateBot యొక్క check_translations కమాండ్ వాటిని ఆటోమేటిక్‌గా పట్టుకుంటుంది:

python manage.py check_translations

locale/nl/LC_MESSAGES/django.po: 0 untranslated, 3 fuzzy
CommandError: Translation check failed

మీ CI పైప్‌లైన్‌కు check_translations --makemessages తో జోడించండి మరియు మీరు మళ్ళీ ఎప్పుడూ fuzzy ఎంట్రీ షిప్ చేయరు.

6. LOCALE_PATHS కాన్ఫిగర్ చేయబడలేదు లేదా తప్పు డైరెక్టరీని సూచిస్తోంది

makemessages ఒక చోట .po ఫైల్‌లను సృష్టిస్తుంది, కానీ Django వాటిని మరెక్కడైనా చూస్తుంది. అనువాదాలు డిస్క్‌లో ఉన్నాయి కానీ ఎప్పుడూ లోడ్ అవ్వవు.

Django నిర్దిష్ట క్రమంలో అనువాద ఫైల్‌లను శోధిస్తుంది: మొదట LOCALE_PATHS డైరెక్టరీలు, ఆపై ప్రతి యాప్ యొక్క locale/ డైరెక్టరీ, మరియు చివరగా ప్రాజెక్ట్ యొక్క locale/ డైరెక్టరీ. LOCALE_PATHS సెట్ చేయబడకపోతే లేదా తప్పు పాత్‌ను సూచిస్తే, Django మీ .po ఫైల్‌లను ఎప్పటికీ కనుగొనకపోవచ్చు.

మీ సెట్టింగ్‌లలో LOCALE_PATHS ను యాబ్సొల్యూట్ పాత్‌కు సెట్ చేయండి:

from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent

LOCALE_PATHS = [
    BASE_DIR / "locale",
]

డైరెక్టరీ ఉందని మరియు ఆశించిన నిర్మాణాన్ని కలిగి ఉందని ధృవీకరించండి:

locale/
    de/
        LC_MESSAGES/
            django.po
            django.mo
    nl/
        LC_MESSAGES/
            django.po
            django.mo

సాధారణ తప్పు ఏమిటంటే LOCALE_PATHS ను యాబ్సొల్యూట్ పాత్ బదులు locale/ (రిలేటివ్) కు సెట్ చేయడం. Django మీ ప్రాజెక్ట్ రూట్ నుండి రిలేటివ్ పాత్‌లను రిజాల్వ్ చేయదు. ఇది ప్రాసెస్ యొక్క వర్కింగ్ డైరెక్టరీపై ఆధారపడుతుంది, ఇది తరచుగా మీరు ఆశించేది కాదు.

7. కాష్ పాత అనువాదాలను అందిస్తోంది

మీరు అనువాదాలను అప్‌డేట్ చేసి కంపైల్ చేశారు, కానీ పాత టెక్స్ట్ కనిపిస్తూనే ఉంటుంది. సర్వర్‌ను రీస్టార్ట్ చేస్తే సరిపోతుంది.

Django యొక్క అనువాద కాటలాగ్ ప్రతి ప్రాసెస్‌కు ఒకసారి లోడ్ అవుతుంది. ప్రొడక్షన్‌లో, Gunicorn లేదా Uvicorn వంటి WSGI/ASGI సర్వర్‌లు వర్కర్ ప్రాసెస్‌లను చాలాకాలం యాక్టివ్‌గా ఉంచుతాయి. .mo ఫైల్ డిస్క్‌లో మారి ఉండవచ్చు, కానీ రన్ అవుతున్న ప్రాసెస్‌లో ఇంకా మెమరీలో పాత అనువాదాలు ఉన్నాయి. అదనంగా, మీరు Django యొక్క కాష్ ఫ్రేమ్‌వర్క్ లేదా Nginx లేదా Cloudflare వంటి రివర్స్ ప్రాక్సీ ఉపయోగిస్తే, కాష్ చేయబడిన రెస్పాన్స్‌లు గడువు ముగిసే వరకు పాత కంటెంట్ అందిస్తాయి.

కొత్త అనువాదాలను డిప్లాయ్ చేసిన తర్వాత మీ అప్లికేషన్ సర్వర్‌ను రీస్టార్ట్ చేయండి:

# Gunicorn
kill -HUP $(cat /tmp/gunicorn.pid)

# Systemd
sudo systemctl restart myapp

# Docker
docker compose restart web

Django యొక్క కాష్ ఫ్రేమ్‌వర్క్ కోసం, అనువాదాలను అప్‌డేట్ చేసిన తర్వాత కాష్ క్లియర్ చేయండి:

from django.core.cache import cache
cache.clear()

డెవలప్‌మెంట్‌లో, runserver Python ఫైల్‌లు మారినప్పుడు ఆటో-రీలోడ్ అవుతుంది కానీ .mo ఫైల్‌లను వాచ్ చేయదు. compilemessages రన్ చేసిన తర్వాత మీరు దాన్ని మాన్యువల్‌గా రీస్టార్ట్ చేయాలి.

8. స్ట్రింగ్‌లు gettext (_() లేదా {% trans %}) లో ర్యాప్ చేయబడలేదు

makemessages కొన్ని స్ట్రింగ్‌లను ఎక్స్‌ట్రాక్ట్ చేయదు, కాబట్టి అవి మీ .po ఫైల్‌లలో ఎప్పుడూ కనిపించవు మరియు ఎప్పుడూ అనువదించబడవు. ఇది అత్యంత ప్రాథమిక సమస్య మరియు పెద్ద కోడ్‌బేస్‌లో అత్యంత సులభంగా అధిగమించగలది.

Django యొక్క makemessages కమాండ్ అనువాద మార్కర్ల కోసం మీ సోర్స్ కోడ్‌ను స్కాన్ చేయడానికి xgettext ఉపయోగిస్తుంది. స్ట్రింగ్ gettext() (సాధారణంగా _() గా ఏలియస్ చేయబడింది), gettext_lazy(), {% trans %}, లేదా {% blocktrans %} లో ర్యాప్ చేయబడకపోతే, ఎక్స్‌ట్రాక్షన్ ప్రాసెస్‌కు అదృశ్యంగా ఉంటుంది.

ప్రతి యూజర్-ఫేసింగ్ స్ట్రింగ్‌ను ర్యాప్ చేయండి:

# Python code
from django.utils.translation import gettext_lazy as _

class Article(models.Model):
    class Meta:
        verbose_name = _("article")
        verbose_name_plural = _("articles")

# Views
from django.utils.translation import gettext as _

def my_view(request):
    message = _("Your changes have been saved.")
    return HttpResponse(message)

<!-- Templates -->
{% load i18n %}
<h1>{% trans "Welcome" %}</h1>
<p>{% blocktrans with count=items|length %}You have {{ count }} items.{% endblocktrans %}</p>

ప్రస్తుతం అనువదించబడని స్ట్రింగ్‌ల ప్రివ్యూ చూడటానికి TranslateBot యొక్క --dry-run ఫ్లాగ్ ఉపయోగించండి, తద్వారా ఎక్స్‌ట్రాక్షన్ సమయంలో మిస్ అయిన స్ట్రింగ్‌లను పట్టుకోవచ్చు:

python manage.py translate --target-lang de --dry-run

ఇది ఎటువంటి API కాల్‌లు లేదా మార్పులు చేయకుండా మీ .po ఫైల్‌లలోని అన్ని అనువదించబడని ఎంట్రీలను చూపిస్తుంది.

9. f-string అనువదించబడదు (Django పరిమితి)

మీరు _() లో f-string ర్యాప్ చేస్తారు మరియు సింటాక్స్ ఎర్రర్ వస్తుంది, లేదా makemessages అనువదించలేని విరిగిన/పాక్షిక స్ట్రింగ్‌ను ఎక్స్‌ట్రాక్ట్ చేస్తుంది.

Python f-string రన్‌టైమ్‌లో ఎవాల్యుయేట్ అవుతాయి. xgettext ఎక్స్‌ట్రాక్షన్ టూల్ సోర్స్ కోడ్‌ను స్టాటిక్‌గా పార్స్ చేస్తుంది, కాబట్టి {} బ్రేసుల లోపల Python ఎక్స్‌ప్రెషన్‌లను ఎవాల్యుయేట్ చేయలేదు. అంటే _(f"Hello, {name}") లిటరల్ {name} ఎక్స్‌ప్రెషన్ కలిగి ఉన్న స్ట్రింగ్‌గా ఎక్స్‌ట్రాక్ట్ అవుతుంది (లేదా పూర్తిగా ఎక్స్‌ట్రాక్ట్ అవ్వడంలో విఫలమవుతుంది), మరియు ఫలిత .po ఎంట్రీ రన్‌టైమ్ స్ట్రింగ్‌తో ఎప్పటికీ సరిపోదు.

బదులుగా Django యొక్క % ఫార్మాటింగ్ లేదా పేరున్న ప్లేస్‌హోల్డర్లతో .format() ఉపయోగించండి:

# Wrong -- f-string cannot be extracted
message = _(f"Hello, {user.name}! You have {count} new messages.")

# Correct -- named placeholders
message = _("Hello, %(name)s! You have %(count)d new messages.") % {
    "name": user.name,
    "count": count,
}

# Also correct -- .format() with positional args
message = _("Hello, {0}! You have {1} new messages.").format(user.name, count)

ఇది TranslateBot లేదా టూలింగ్ పరిమితి కాదు. gettext ఎలా పనిచేస్తుందో దానికి ఇది ప్రాథమికమైనది. సోర్స్ స్ట్రింగ్ రన్‌టైమ్‌లో ఎక్స్‌ట్రాక్ట్ చేయబడి లుక్‌అప్ చేయబడేలా స్టాటిక్ లిటరల్ అయి ఉండాలి.

TranslateBot అనువాదం సమయంలో ఈ ప్లేస్‌హోల్డర్ ఫార్మాట్‌లన్నింటినీ (%(name)s, {0}, %s, HTML ట్యాగ్‌లు) భద్రపరుస్తుంది, కాబట్టి అనువదించిన స్ట్రింగ్‌లు పూర్తిగా ఫంక్షనల్‌గా ఉంటాయి.

10. ప్లేస్‌హోల్డర్ ఫార్మాట్ స్ట్రింగ్ ఎర్రర్‌లు .po కంపైలేషన్‌ను విచ్ఛిన్నం చేస్తున్నాయి

compilemessages ఎర్రర్‌తో విఫలమవుతుంది, లేదా .po ఫైల్‌లో #, python-format ఫ్లాగ్ అసమతుల్యత ఉంది, మరియు ఎంట్రీ నిశ్శబ్దంగా తొలగించబడుతుంది.

సోర్స్ స్ట్రింగ్‌లో %(name)s వంటి Python ఫార్మాట్ ప్లేస్‌హోల్డర్‌లు ఉన్నప్పుడు, Django .po ఎంట్రీని #, python-format తో గుర్తిస్తుంది. అనువాదంలో వేరే ప్లేస్‌హోల్డర్‌లు ఉంటే (%(nome)s వంటి టైపో, మిస్సింగ్ ప్లేస్‌హోల్డర్, లేదా అదనపు ప్లేస్‌హోల్డర్) gettext టూల్స్ ఎంట్రీని తిరస్కరించవచ్చు లేదా compilemessages విఫలమవ్వవచ్చు. ఇది సాధారణంగా మాన్యువల్ అనువాదాలతో లేదా ప్లేస్‌హోల్డర్ సెమాంటిక్స్ అర్థం చేసుకోని AI అనువాద టూల్స్‌తో జరుగుతుంది.

విరిగిన ఎంట్రీ ఇలా కనిపిస్తుంది:

#, python-format
msgid "Hello, %(name)s! You have %(count)d new messages."
msgstr "Hallo, %(naam)s! Je hebt %(count)d nieuwe berichten."

ఇక్కడ %(naam)s %(name)s అయి ఉండాలి. ప్లేస్‌హోల్డర్‌లు సోర్స్‌తో ఖచ్చితంగా సరిపోవాలి.

అనువదించిన స్ట్రింగ్‌లలో సోర్స్ లాగే ఖచ్చితంగా అదే ప్లేస్‌హోల్డర్‌లు ఉన్నాయని నిర్ధారించుకోండి. టైపోలు, మిస్సింగ్ ప్లేస్‌హోల్డర్‌లు, మరియు అదనపు ప్లేస్‌హోల్డర్‌లను తనిఖీ చేయండి.

TranslateBot నిజమైన ప్రయోజనాన్ని అందించే ప్రాంతం ఇది. దాని ప్లేస్‌హోల్డర్ భద్రత లాజిక్ అనువదించిన అవుట్‌పుట్‌లోని అన్ని ఫార్మాట్ స్ట్రింగ్‌లు (%(name)s, {0}, %s) సోర్స్‌తో ఖచ్చితంగా సరిపోయేలా నిర్ధారిస్తుంది. ప్లేస్‌హోల్డర్ హ్యాండ్లింగ్ 100% టెస్ట్ కవరేజ్‌తో కవర్ చేయబడింది, కాబట్టి అనువాదం నుండి ఫార్మాట్ స్ట్రింగ్ ఎర్రర్‌లు కంపైల్ టైమ్‌లో పట్టుబడే బదులు టూల్ స్థాయిలో తొలగించబడతాయి.

మీరు మాన్యువల్‌గా లేదా ప్లేస్‌హోల్డర్‌లను హ్యాండిల్ చేయని టూల్‌తో అనువదిస్తే, మీ .po ఫైల్‌లను దీనితో వ్యాలిడేట్ చేయండి:

msgfmt --check-format locale/de/LC_MESSAGES/django.po

ఇది gettext యొక్క ఫార్మాట్ స్ట్రింగ్ వ్యాలిడేషన్ రన్ చేస్తుంది మరియు ఏదైనా అసమతుల్యతను రిపోర్ట్ చేస్తుంది.

అన్నీ కలిపి: ఒక రక్షణాత్మక వర్క్‌ఫ్లో

ఈ సమస్యలలో చాలా వరకు ఒక సాధారణ మూల కారణాన్ని పంచుకుంటాయి: మర్చిపోవడం సులభమైన మాన్యువల్ స్టెప్‌లు. ఇది అన్ని 10 సమస్యలను నివారించే వర్క్‌ఫ్లో:

# 1. Extract strings (catches #8 -- any new gettext-wrapped strings)
python manage.py makemessages -a --no-obsolete

# 2. Translate (catches #1, #5, #8, #9, #10 -- handles untranslated,
#    fuzzy, and placeholder issues automatically)
python manage.py translate

# 3. Compile (catches #1 -- generates .mo files)
python manage.py compilemessages

# 4. Verify in CI (catches everything that slipped through)
python manage.py check_translations --makemessages

స్టెప్ 4 ను మీ CI పైప్‌లైన్‌కు జోడించండి మరియు అనువదించబడని స్ట్రింగ్‌లు, fuzzy ఎంట్రీలు, మరియు ఫార్మాట్ ఎర్రర్‌లు ప్రొడక్షన్‌కు చేరుకోవడానికి ముందే బిల్డ్‌ను విఫలం చేస్తాయి.

త్వరిత సూచన పట్టిక

మీరు అనువాద స్టెప్‌ను ఆటోమేట్ చేసి CI లో తనిఖీలను అమలు చేసినప్పుడు ఈ సమస్యలలో చాలా వరకు అదృశ్యమవుతాయి. TranslateBot యొక్క translate కమాండ్ ప్లేస్‌హోల్డర్ భద్రత మరియు ఇంక్రిమెంటల్ అనువాదాన్ని హ్యాండిల్ చేస్తుంది, అయితే check_translations ప్రొడక్షన్‌కు చేరుకోవడానికి ముందే తప్పించుకున్న ప్రతిదాన్ని (అనువదించబడని ఎంట్రీలు, fuzzy ఫ్లాగ్‌లు, మరియు ఫార్మాట్ స్ట్రింగ్ సమస్యలు) పట్టుకుంటుంది.