15 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
AI ਨਾਲ ਬਹੁਭਾਸ਼ੀ ਅਤੇ ਬਹੁ-ਖੇਤਰੀ ਐਪ ਬਣਾਉਣ: ਇੱਕ ਗਾਈਡ
i18n, ਖੇਤਰੀ ਰੂਟਿੰਗ, ਡੇਟਾ ਨਿਯਮ ਅਤੇ ਸਮੱਗਰੀ ਵਰਕਫਲੋ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼; ਅਨੁਵਾਦ ਤੇ ਗਲਤੀਆਂ ਘਟਾਉਣ ਲਈ AI ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰੋ।
i18n, ਖੇਤਰੀ ਰੂਟਿੰਗ, ਡੇਟਾ ਨਿਯਮ ਅਤੇ ਸਮੱਗਰੀ ਵਰਕਫਲੋ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼; ਅਨੁਵਾਦ ਤੇ ਗਲਤੀਆਂ ਘਟਾਉਣ ਲਈ AI ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰੋ।
ਇੱਕ ਬਹੁਭਾਸ਼ੀ ਐਪ ਮੁੱਖ ਤੌਰ 'ਤੇ ਭਾਸ਼ਾ ਬਾਰੇ ਹੁੰਦੀ ਹੈ: UI ਸਤਰਾਂ, ਸੁਨੇਹੇ, ਈਮੇਲ, ਸਹਾਇਤਾ ਸਮੱਗਰੀ ਅਤੇ ਕੋਈ ਵੀ ਯੂਜ਼ਰ-ਜਨਰੇਟ ਜਾਂ ਸਿਸਟਮ ਜਨਰੇਟ ਕਾਪੀ ਜੋ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਕੁਦਰਤੀ ਲੱਗਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਬਹੁ-ਖੇਤਰੀ ਐਪ ਇਸ ਗੱਲ ਬਾਰੇ ਹੁੰਦੀ ਹੈ ਕਿ ਅਨੁਭਵ ਕਿੱਥੇ ਅਤੇ ਕਿਹੜੇ ਨਿਯਮਾਂ ਦੇ ਅਧੀਨ ਦਿੱਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਖੇਤਰ ਸਿਰਫ ਅਨੁਵਾਦ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ: ਮੁਦਰਾ ਅਤੇ ਟੈਕਸ, ਟਾਈਮਜ਼ੋਨ ਅਤੇ ਤਾਰੀਖ ਫਾਰਮੇਟ, ਮਾਪ-ਇਕਾਈਆਂ, ਫੀਚਰਾਂ ਦੀ ਉਪਲਬਧਤਾ, ਡੇਟਾ ਰਿਹਾਇਸ਼ ਅਤੇ ਪ੍ਰਾਈਵੇਸੀ ਮੰਗਾਂ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਕਾਨੂੰਨੀ ਸ਼ਬਦਾਵਲੀ ਵੀ।
ਭਾਵ-ਕਰੋ ਕਿ ਭਾਸ਼ਾ "ਅਸੀਂ ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਦੇ ਹਾਂ" ਹੈ, ਅਤੇ ਖੇਤਰ "ਕਿਹੜੇ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ"। ਤੁਸੀਂ ਹੋ ਸਕਦਾ ਹੈ:
ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਜਾਣਦੀਆਂ ਗਲਤੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ "ਲੋਕਲ" ਭੂਤਕਤੀ ਸਿਰਫ ਸਤਰਾਂ 'ਤੇ ਨਿਰਭਰ ਹੈ। ਇਹ ਸਿਰਫ ਸਤਰਾਂ ਹੀ ਨਹੀਂ ਹਨ:
AI ਬਹੁਤ ਸਾਰਾ ਰੁਟੀਨ ਕੰਮ ਹਟਾ ਸਕਦਾ ਹੈ: ਅਨੁਵਾਦਾਂ ਦਾ ਡਰਾਫਟ, ਇੱਕਸਾਰ ਟਰਮੀਨੋਲੋਜੀ ਦੀ ਸੁਝਾਅ, ਅਣਅਨੁਵਾਦਿਤ ਸਤਰਾਂ ਦੀ ਖੋਜ, ਅਤੇ ਤੁਹਾਡੇ ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਵਰਕਫਲੋ ਵਿੱਚ ਤੇਜ਼ੀ। ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਅਨੁਸੰਗਤਾ ਚੈੱਕਸ ਵਿੱਚ ਮਜ਼ਬੂਤ ਹੈ।
ਪਰ ਇਹ ਜਾਦੂ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਸਾਫ਼ ਸੋਰਸ ਕਾਪੀ, ਕਾਨੂੰਨੀ/ਕੰਪਲਾਇੰਸ ਟੈਕਸਟ ਲਈ ਮਾਲਕੀ ਅਤੇ ਉੱਚ-ਖਤਰੇ ਵਾਲੀ ਸਮੱਗਰੀ ਲਈ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
ਇਹ ਗਾਈਡ ਵਿਹਾਰਕ ਰਹੇਗੀ: ਪੈਟਰਨ ਜੋ ਤੁਸੀਂ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ, ਟਰੇਡ-ਆਫ਼ ਜਿਨ੍ਹਾਂ 'ਤੇ ਧਿਆਨ ਦੇਣਾ ਹੈ, ਅਤੇ ਚੈਕਲਿਸਟ ਜੋ ਤੁਸੀਂ ਰਾਊਟਿੰਗ, ਡੇਟਾ ਰਿਹਾਇਸ਼, ਭੁਗਤਾਨ ਅਤੇ ਸਕੇਲਬਲ ਅਨੁਵਾਦ ਵਰਕਫਲੋ ਵਿੱਚ ਲਿਆਉਂਦੇ ਸਮੇਂ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ ਹੋ।
ਉਪਕਰਨਾਂ ਨੂੰ ਚੁਣਨ (ਜਾਂ AI ਟ੍ਰਾਂਸਲੇਟਰ ਨੂੰ ਪ੍ਰੌਂਪਟ ਕਰਨ) ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਾਫ਼ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਉਤਪਾਦ ਲਈ "ਅਲੱਗ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਬਹੁਭਾਸ਼ੀ ਅਤੇ ਬਹੁ-ਖੇਤਰੀ ਕੰਮ ਸਭ ਤੋਂ ਵੱਧ ਉਸ ਵੇਲੇ ਨਾਕਾਮ ਹੁੰਦੇ ਹਨ ਜਦ ਟੀਮਾਂ ਸਮਝਦੀਆਂ ਹਨ ਕਿ ਇਹ ਸਿਰਫ UI ਸਤਰ ਹੈ।
ਸ਼ੁਰੂਆਤ ਇੱਕ ਛੋਟੀ ਇਨਵੈਂਟਰੀ ਨਾਲ ਕਰੋ ਕਿ ਕੀ-ਕੀ ਚੀਜ਼ਾਂ ਭਾਸ਼ਾ ਅਤੇ ਖੇਤਰ ਮੁਤਾਬਕ ਵੱਧਦੀਆਂ/ਘਟਦੀਆਂ ਹਨ:
en-GB vs en-US), ਅਤੇ ਕਿਹੜੇ ਦੇਸ਼ਾਂ ਵਿੱਚ ਤੁਸੀਂ ਓਪਰੇਟ ਕਰੋਗੇ।ਇਹਨਾਂ ਨੂੰ “ਜਰੂਰੀ” ਅਤੇ “ਬਾਅਦ ਵਿੱਚ” ਵੱਲ ਵੰਡੋ—ਕਿਉਂਕਿ ਸਕોપ ਕ੍ਰੀਪ ਰਿਲੀਜ਼ਜ਼ ਨੂੰ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਮੰਦ ਕਰਦਾ ਹੈ।
ਸ਼ੁਰੂ ਤੋਂ ਕੁਝ ਮੈਟ੍ਰਿਕ ਚੁਣੋ:
ਸਪੱਸ਼ਟ ਹੋਵੋ ਕਿ ਕਿਹੜੇ ਸਤਹ—ਸਿਰਫ "ਐਪ" ਨਹੀਂ:
UI ਸਤਰ, ਆਨਬੋਰਡਿੰਗ, ਲੈਣਦੈਨਈਮੇਲ, ਇਨਵਾਇਸ/ਰਸੀਦਾਂ, ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਸਹਾਇਤਾ ਡੌਕਸ, ਮਾਰਕੇਟਿੰਗ ਪੇਜ, ਐਰਰ ਸੁਨੇਹੇ, ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਵੀ ਸਕ੍ਰੀਨਸ਼ਾਟ।
ਇੱਕ ਮੈਟ੍ਰਿਕਸ ਸਾਰਿਆਂ ਨੂੰ ਏਲੀਨ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਕੰਬੀਨੇਸ਼ਨ ਸਮਰਥਨ ਕਰ ਰਹੇ ਹੋ।
| Locale | Region | Currency | ਨੋਟਸ |
|---|---|---|---|
| en-US | US | USD | Sales tax ਹੇਠਾਂ ਸਟੇਟ ਦੇ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਹੁੰਦੀ ਹੈ |
| en-GB | GB | GBP | ਕੀਮਤ ਦਿਖਾਉਣ 'ਚ VAT ਸ਼ਾਮਲ |
| fr-FR | FR | EUR | ਆਧਿਕਾਰਕ ਲਹਿੱਜਾ, ਲੋਕਲ ਕਾਨੂੰਨੀ ਪੇਜ |
| es-MX | MX | MXN | ਲੋਕਲ ਭੁਗਤਾਨ ਵਿਧੀਆਂ ਦੀ ਲੋੜ |
ਇਹ ਮੈਟ੍ਰਿਕਸ ਤੁਹਾਡਾ ਸਕੋਪ ਕਾਂਟ੍ਰੈਕਟ ਬਣ ਜਾਂਦਾ ਹੈ: ਰੂਟਿੰਗ, ਫਾਰਮੇਟਿੰਗ, ਅਨੁਕੂਲਤਾ, ਭੁਗਤਾਨ ਅਤੇ QA ਸਭ ਇਸਦੇ ਹਵਾਲੇ ਕਰਨ।
ਤੁਹਾਡੀ i18n ਨੀਂਹ ਉਹ "ਉਬਾਉ" ਹਿੱਸਾ ਹੈ ਜੋ ਮਹਿੰਗੀਆਂ ਰੀ-ਵਰਕਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ। ਇੱਕ ਵੀ ਸਤਰ ਅਨੁਵਾਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਉਤਪਾਦ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਭਾਸ਼ਾ ਅਤੇ ਖੇਤਰਿਕ پسند ਨੂੰ ਕਿਵੇਂ ਪਛਾਣੇਗਾ, ਜਦ ਕੁਝ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਵਿਹਾਰ ਕੀ ਹੋਵੇਗਾ, ਅਤੇ ਦੈਨੀਕ ਜਾਣਕਾਰੀ (ਪੈਸਾ, ਤਾਰੀਖਾਂ, ਨਾਂ) ਨੂੰ ਇਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਫਾਰਮੇਟ ਕੀਤਾ ਜਾਵੇ।
ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਆਪਣੀਆਂ ਲੋਕੇਲਾਂ ਨੂੰ ਭਾਸ਼ਾ-ਕੇਵਲ (fr) ਰੱਖੋਗੇ ਜਾਂ ਭਾਸ਼ਾ-ਖੇਤਰ (fr-CA)। ਭਾਸ਼ਾ-ਕੇਵਲ ਸਧਾਰਨ ਹੈ, ਪਰ ਜਦ ਖੇਤਰੀ ਫਰਕ ਮਹੱਤਵਪੂਰਨ ਹਨ ਤਾਂ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ: ਸ਼ਬਦ-ਲਿਪੀ, ਕਾਨੂੰਨੀ ਟੈਕਸਟ, ਸਪੋਰਟ ਘੰਟੇ, ਅਗਰ ਤੁਹਾਨੂੰ ਜਲਦੀ ਵੱਖਰੀ ਸਮੱਗਰੀ ਦੀ ਲੋੜ ਪਏਗੀ ਤਾਂ ਭਾਸ਼ਾ-ਖੇਤਰ ਵਰਤੋ।
ਪ੍ਰਯੋਗਿਕ ਰਵੱਈਆ:
language-region ਵਰਤੋ (en-US, en-GB, pt-BR, pt-PT).ਫੌਲਬੈਕ ਉਮੀਦਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਨਿਰਧਾਰਿਤ ਕਰੋ:
fr-CA ਲਈ ਕੁੰਜੀ ਨਹੀਂ ਹੈ ਤਾਂ ਕੀ fr ਫਿਰ en ਤੇ ਜਾਏਗੀ?ਲੋਕੇਲ-ਅਵੇਅਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਰਤੋ:
ਕੁੰਜੀਆਂ ਨੂੰ ਸਥਿਰ ਅਤੇ ਵਰਣਨਾਤਮਕ ਬਣਾਓ — ਅੰਗਰੇਜ਼ੀ phrasing ਨਾਲ ਬੰਨ੍ਹਿਆ ਨਾ ਕਰੋ। ਉਦਾਹਰਨ:
checkout.payment_method.title
errors.rate_limit.body
settings.notifications.email.label
ਜਿੱਥੇ ਫਾਇਲਾਂ ਰਹੰਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ: /locales/{locale}.json) ਦਸਤਾਵੇਜ਼ ਕਰੋ ਅਤੇ ਕੋਡ ਰਿਵਿਊ ਵਿੱਚ ਇਹ ਰਿਵਾਜ ਲਾਗੂ ਕਰੋ। ਇਹ ਆਧਾਰ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ AI-ਸਹਾਇਤ ਅਨੁਵਾਦ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਆਟੋਮੇਟੇਬਲ ਬਣਾਉਂਦਾ ਹੈ।
ਚੰਗੀ ਰੂਟਿੰਗ ਐਪ ਨੂੰ "ਲੋਕਲ" ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ ਬਿਨਾਂ ਇਸਦੇ ਕਿ ਉਪਭੋਗਤਾ ਨੂੰ ਸੋਚਣਾ ਪਵੇ। ਕੁੰਜੀ ਇਹੋ ਹੈ ਕਿ ਭਾਸ਼ਾ (ਉਹ ਜੋ ਲੋਕ ਪੜ੍ਹਦੇ ਹਨ) ਨੂੰ ਖੇਤਰ (ਜੋ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ) ਤੋਂ ਅਲੱਗ ਰੱਖਿਆ ਜਾਵੇ।
ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਤਰੀਕੇ ਹਨ ਅਤੇ ਕਈ ਉਤਪਾਦ ਇਸਨਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਵਰਤਦੇ ਹਨ:
ਵਰਤਣ ਲਈ ਪ੍ਰਭਾਵੀ ਨਿਯਮ: ਆਖਰੀ ਸਪੱਸ਼ਟ ਚੋਣ ਨੂੰ ਯਾਦ ਰੱਖੋ, ਅਤੇ ਸਿਰਫ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਹੋਰ ਕੋਈ ਸਿਗਨਲ ਨਾ ਹੋਵੇ ਤਾਂ ਆਟੋ-ਡੀਟੈਕਟ ਕਰੋ।
URL ਰਣਨੀਤੀ ਜਲਦੀ ਚੁਣੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ ਬਦਲਣਾ SEO ਅਤੇ ਸ਼ੇਅਰਡ ਲਿੰਕਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।
/en-us/…, /fr-fr/… (ਹੋਸਟ ਕਰਨ ਲਈ ਸਧਾਰਨ, ਯੂਜ਼ਰਾਂ ਲਈ ਸਾਫ; CDN ਨਾਲ ਚੰਗਾ ਕੰਮ)us.example.com, fr.example.com (ਸੁਥਰਾ ਵਿਭਾਜਨ; ਜ਼ਿਆਦਾ DNS/ਸਰਟੀਫਿਕੇਟ ਸੈਟਅੱਪ ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਜਟਿਲਤਾ)?lang=fr®ion=CA (ਆਸਾਨ ਲਾਗੂ, ਪਰ SEO ਲਈ ਘੱਟ-ਲਾਇਕ)ਅਕਸਰ ਟੀਮਾਂ ਲਈ ਪਾਥ ਪ੍ਰੀਫਿਕਸ ਸਾਰਥਕ ਡਿਫੌਲਟ ਹੈ।
ਲੋਕਲਾਈਜ਼ਡ ਪੇਜਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ:
x-default ਤੁਹਾਡੇ ਗਲੋਬਲ ਫੌਲਬੈਕ ਲਈ।ਫਰੰਟ-ਐਂਡ ਰੂਟਿੰਗ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਕੀ ਵੇਖਦਾ ਹੈ, ਪਰ ਖੇਤਰੀ ਰੂਟਿੰਗ ਇਹ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਬੇਨਤੀ ਕਿੱਥੇ ਜਾ ਰਹੀ ਹੈ। ਉਦਾਹਰਨ: /en-au/ ਉੱਤੇ ਉਪਭੋਗਤਾ ਨੂੰ AU ਪ੍ਰਾਈਸਿੰਗ ਸੇਵਾ, AU ਟੈਕਸ ਨਿਯਮ, ਅਤੇ ਜਦ ਲੋੜ ਹੋਵੇ ਤਾਂ AU ਡੇਟਾ ਸਟੋਰੇਜ ਨਾਲ ਕਨੈਕਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ — ਭਲੇ UI ਭਾਸ਼ਾ English ਹੋਵੇ।
ਇੱਕੋ "region" ਮੁੱਲ ਨੂੰ ਬੇਨਤੀਆਂ ਰਾਹੀਂ ਪਾਸ ਕਰਕੇ ਇਸਨੂੰ ਇਕਸਾਰ ਰੱਖੋ (ਹੈਡਰ, ਟੋਕਨ ਕਲੇਮ, ਜਾਂ ਸੈਸ਼ਨ) ਅਤੇ ਇਸਦੇ ਆਧਾਰ 'ਤੇ ਸਹੀ ਬੈਕਐਂਡ ਏਂਡਪੌਇੰਟ ਅਤੇ ਡੇਟਾਬੇਸ ਚੁਣੋ।
ਡੇਟਾ ਰਿਹਾਇਸ਼ ਦਾ ਅਰਥ ਹੈ ਤੁਹਾਡੇ ਗਾਹਕਾਂ ਦਾ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਅਤੇ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਹੁ-ਖੇਤਰੀ ਐਪਾਂ ਲਈ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਕਈ ਸੰਗਠਨਾਂ (ਅਤੇ ਕੁਝ ਨਿਯਮ) ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਕਿਸੇ ਦੇਸ਼ ਜਾਂ ਆਰਥਿਕ ਖੇਤਰ ਦੇ ਲੋਕਾਂ ਬਾਰੇ ਡੇਟਾ ਨਿਰਧਾਰਿਤ ਭੂਗੋਲਿਕ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਰਹੇ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਵਧੇਰੇ ਸੁਰੱਖਿਆ ਦੇ ਕੇ ਸੰਭਾਲਿਆ ਜਾਵੇ।
ਇਹ ਭਰੋਸੇ ਦਾ ਵੀ ਮਾਮਲਾ ਹੈ: ਗਾਹਕ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਅਣਇਛਿਤ ਤਰੀਕੇ ਨਾਲ ਸਰਹੱਦਾਂ ਤੋਂ ਪਾਰ ਕੀਤਾ ਜਾਵੇ।
ਪਹਿਲਾਂ ਉਹ ਸੂਚੀ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਸੰਗ੍ਰਹਿ ਕਰਦੇ ਹੋ ਅਤੇ ਇਹ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ। ਆਮ ਸੰਵੇਦਨਸ਼ੀਲ ਵਰਗੀਕਰਨ:
ਫਿਰ ਇਹ ਸ਼੍ਰੇਣੀਆਂ ਸਟੋਰੇਜ ਸਥਾਨਾਂ ਵਿੱਚ ਨਕਸ਼ਾ ਕਰੋ: ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ, ਐਨਾਲਿਟਿਕਸ ਟੂਲ, ਲੌਗ, ਡੇਟਾ ਵੇਅਰਹਾਊਸ, ਖੋਜ ਇੰਡੈਕਸ, ਬੈਕਅੱਪ ਅਤੇ ਤੀਜੇ-ਪੱਖੀ ਪ੍ਰਦਾਤਾ। ਟੀਮਾਂ ਅਕਸਰ ਭੁੱਲ ਜਾਂਦੀਆਂ ਹਨ ਕਿ ਲੌਗ ਅਤੇ ਬੈਕਅੱਪ ਕੇਂਦਰੀਕ੍ਰਿਤ ਹੋਣ ਨਾਲ ਰਿਹਾਇਸ਼ ਉਮੀਦਾਂ ਨੂੰ ਗਲਤ ਢੰਗ ਨਾਲ ਤੋੜ ਸਕਦੀਆਂ ਹਨ।
ਇਕ "ਸਹੀ" ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਪਰ ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਫ ਨੀਤੀ ਅਤੇ ਉਸਨੂੰ ਮਿਲਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਚਾਹੀਦੀ ਹੈ।
1) ਰੀਜਨਲ ਡੇਟਾਬੇਸ (ਮਜ਼ਬੂਤ ਅਲੱਗੋ)
EU ਯੂਜ਼ਰਾਂ ਨੂੰ EU ਡੇਟਾ ਸਟੋਰਾਂ ਵਿੱਚ ਰੱਖੋ, US ਯੂਜ਼ਰਾਂ ਨੂੰ US ਡੇਟਾ ਸਟੋਰ ਵਿੱਚ। ਇਹ ਰਿਹਾਇਸ਼ ਲਈ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਹੈ ਪਰ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਵਧਾਉਂਦਾ ਹੈ।
2) ਸਾਂਝੇ ਸਿਸਟਮ ਵਿੱਚ ਪਾਰਟੀਸ਼ਨ (ਕੰਟਰੋਲਡ ਅਲੱਗੋ)
ਰੀਜਨ-ਅਧਾਰਿਤ ਪਾਰਟੀਸ਼ਨਾਂ/ਸਕੀਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ ਐਪ ਲੇਅਰ ਅਤੇ IAM ਨਿਯਮਾਂ ਰਾਹੀਂ "ਕੋਈ ਕ੍ਰਾਸ-ਰੀਜਨ ਰੀਡ/ਰਾਈਟ ਨਾ ਹੋਵੇ" ਨੂੰ ਲਾਗੂ ਕਰੋ।
3) ਏਨਕ੍ਰਿਪਸ਼ਨ ਬਾਊਂਡਰੀਜ਼ (ਖਤਰੇ ਘਟਾਓ)
ਡੇਟਾ ਨੂੰ ਕਿਸੇ ਵੀ ਥਾਂ ਸਟੋਰ ਕਰੋ, ਪਰ ਰੀਜਨ-ਵਿਸ਼ੇਸ਼ ਏਨਕ੍ਰਿਪਸ਼ਨ ਕੀਜ਼ ਰੱਖੋ ਤਾਂ ਕਿ ਕੇਵਲ ਉਸ ਖੇਤਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਹੀ ਸੰਵੇਦਨਸ਼ੀਲ ਫੀਲਡ ਡੀਕ੍ਰਿਪਟ ਕਰ ਸਕਣ। ਇਹ ਖਤਰਾ ਘਟਾ ਸਕਦਾ ਹੈ, ਪਰ ਕੇਵਲ ਇਨ੍ਹਾਂ ਨਾਲ ਸਖਤ ਰਿਹਾਇਸ਼ ਮੰਗਾਂ ਪੂਰੀ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ।
ਕੰਪਲਾਇੰਸ ਨੂੰ ਜਾਂਚ ਕਰਨ ਯੋਗ ਮੰਗਾਂ ਵਜੋਂ ਲਵੋ:
/security)ਤੁਹਾਡੇ ਖਾਸ ਹਾਲਾਤ ਲਈ ਕਾਨੂੰਨੀ ਸਲਾਹ ਲਵੋ—ਇਹ ਅੰਸ਼ ਤਕਨੀਕੀ ਨੀਂਹ ਬਣਾਉਣ ਬਾਰੇ ਹੈ ਬਿਨਾਂ ਅਜਿਹੇ ਵਾਅਦ ਕਰਨ ਦੇ ਜੋ ਤੁਸੀਂ ਜਾਂਚ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਭੁਗਤਾਨ ਅਤੇ ਮੁੱਲ ਉਹ ਸਥਾਨ ਹਨ ਜਿੱਥੇ "ਬਹੁ-ਖੇਤਰੀ" ਹਕੀਕਤ ਬਣ ਜਾਂਦਾ ਹੈ। ਦੋ ਯੂਜ਼ਰ ਇਕੋ ਪੰਨਾ ਇਕੋ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਖ ਸਕਦੇ ਹਨ ਪਰ ਫਿਰ ਵੀ ਵੱਖ-ਵੱਖ ਕੀਮਤਾਂ, ਟੈਕਸ, ਇਨਵੌਇਸ ਅਤੇ ਭੁਗਤਾਨ ਵਿਧੀਆਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਚੀਜ਼ਾਂ ਲਿਸਟ ਕਰੋ ਜੋ ਦੇਸ਼/ਖੇਤਰ ਅਨੁਸਾਰ ਵੱਖਰੀਆਂ ਹਨ ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਹਰ ਨਿਯਮ ਦਾ "ਮਾਲਕ" ਕੌਣ ਹੈ (ਪ੍ਰੋਡਕਟ, ਫਾਇਨੈਨਸ, ਲੀਗਲ)। ਆਮ ਫਰਕ:
ਇਹ ਇਨਵੈਂਟਰੀ ਤੁਹਾਡਾ ਸੋਰਸ ਆਫ਼ ਟ੍ਰੂਥ ਬਣ ਜਾਂਦੀ ਹੈ ਅਤੇ UI ਵਿੱਚ ਬੇਹੁਦੇ ਐਕਸੈਪਸ਼ਨ ਰੋਕਦੀ ਹੈ।
ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਖੇਤਰੀ ਕੀਮਤ ਸੂਚੀ ਰੱਖੋਗੇ (ਅਨੁਮਾਨਿਤ ਮਾਰਜਿਨ ਲਈ ਸਿਫਾਰਸ਼ੀ) ਜਾਂ ਇੱਕ ਬੇਸ ਕਰੰਸੀ ਤੋਂ ਬਦਲਾਅ ਕਰੋਗੇ। ਜੇ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ:
ਇਹ ਨਿਯਮ ਚੈੱਕਆਉਟ, ਈਮੇਲ, ਰਸੀਦਾਂ ਅਤੇ ਰਿਫੰਡ 'ਚ ਇੱਕਸਾਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ — ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਭਰੋਸਾ ਗੁਆਣ ਦਾ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਟੋਟਲ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਬਦਲ ਜਾਵੇ।
ਭੁਗਤਾਨ UX ਅਕਸਰ ਫਾਰਮ ਅਤੇ ਵੈਰਿਫਿਕੇਸ਼ਨ 'ਤੇ ਟੁਟ ਜਾਂਦੀ ਹੈ। ਖੇਤਰੀ ਬਣਾਓ:
ਜੇ ਤੁਸੀਂ ਤੀਜੀ-ਪੱਖ ਭੁਗਤਾਨ ਪੰਨੇ ਵਰਤਦੇ ਹੋ ਤਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹ ਤੁਹਾਡੇ ਲੋਕੇਲਾਂ ਅਤੇ ਖੇਤਰੀ ਅਨੁਕੂਲਤਾ ਮੰਗਾਂ ਨੂੰ ਸਹਾਰਦੇ ਹਨ।
ਕੁਝ ਖੇਤਰਾਂ ਵਿੱਚ ਤੁਹਾਨੂੰ ਫੀਚਰ ਬੰਦ ਕਰਨੇ, ਉਤਪਾਦ ਛੁਪਾਉਣੇ ਜਾਂ ਵੱਖਰੇ ਨਿਯਮ ਦਿਖਾਉਣੇ ਪੈ ਸਕਦੇ ਹਨ। ਇਹ ਗੇਟਿੰਗ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਵਜੋਂ (ਬਿਲਿੰਗ ਦੇਸ਼ ਆਧਾਰ) ਲਾਗੂ ਕਰੋ, ਭਾਸ਼ਾ ਦੁਆਰਾ ਨਹੀਂ।
AI ਪ੍ਰਦਾਤਾ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਸਾਰ ਦੇਣ ਅਤੇ ਨਿਯਮ ਟੇਬਲ ਡ੍ਰਾਫਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕੀਮਤਾਂ, ਟੈਕਸ ਜਾਂ ਕਾਨੂੰਨੀ ਟੈਕਸਟ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀਆਂ ਚੀਜ਼ਾਂ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਨਾਲ ਹੀ ਅਕੀਦਤ ਦੇਵੋ।
ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਸਕੇਲ ਕਰਨ ਲਈ ਤੇਜ਼ ਅਨੁਵਾਦ ਹੀ ਸਰਪ੍ਰਾਇਜ਼ ਨਹੀਂ ਹੈ—ਇਹ ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਸਮੱਗਰੀ ਪੇਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਸ ਨੇ ਉਨੂੰ ਅਨੁਵਾਦ ਕੀਤਾ, ਅਤੇ ਕਿਵੇਂ ਬਦਲਾਵ ਡਰਾਫਟ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਜਾਂਦੇ ਹਨ।
UI ਮਾਈਕ੍ਰੋਕੋਪੀ (ਬਟਨ, ਐਰਰ, ਨੈਵੀਗੇਸ਼ਨ) ਨੂੰ ਕੋਡ ਸਤਰਾਂ ਵਜੋਂ ਜਿਣੋ ਜੋ ਐਪ ਨਾਲ ਛੁੱਟਦੇ ਹਨ, ਆਮ ਤੌਰ 'ਤੇ ਟਰਾਂਸਲੇਸ਼ਨ ਫਾਇਲਾਂ ਵਿੱਚ ਰਿਪੋ ਵਿੱਚ ਮੈਨੇਜ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਮਾਰਕੇਟਿੰਗ ਪੇਜ, ਸਹਾਇਤਾ ਲੇਖ ਅਤੇ ਲੰਬਾ-ਫਾਰਮ ਕਾਪੀ ਨੂੰ ਇੱਕ CMS ਵਿੱਚ ਰੱਖੋ ਜਿੱਥੇ ਐਡੀਟਰਾਂ ਨੂੰ ਡਿਪਲੋਇਮੈਂਟ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਮੰਨੀ ਜਾਵੇ।
ਇਹ ਵੰਡ ਇਸ ਆਮ ਨੁਕਸਾਨ ਨੂੰ ਰੋਕਦੀ ਹੈ: ਇੰਜੀਨੀਅਰਾਂ ਦਾ CMS ਸਮੱਗਰੀ 'ਚ ਸੁਧਾਰ ਕਰਕੇ "ਅਨੁਵਾਦ ਠੀਕ ਕਰਨ" ਲਈ ਇੰਟਰਨੈਟ ਕੀਤਾ ਜਾਣਾ ਜਾਂ ਐਡੀਟਰਾਂ ਦਾ UI ਟੈਕਸਟ ਬਦਲਣਾ ਜੋ ਰਿਲੀਜ਼-ਸਹਿਤ ਵਰਜਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਕੇਲਬਲ ਲਾਈਫਸਾਈਕਲ ਸਧਾਰਨ ਅਤੇ ਦੁਹਰਾਏ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਮਾਲਕੀ ਸਪਸ਼ਟ ਬਣਾਓ:
ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਉਸ ਵੇਲੇ ਟੁੱਟਦੀ ਹੈ ਜਦ ਟੀਮਾਂ ਨੂੰ ਪਤਾ ਨਾ ਹੋਵੇ ਕਿ ਕੀ ਬਦਲਿਆ। ਰਿਲੀਜ਼ਾਂ ਨਾਲ ਸਤਰਾਂ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ, ਸੋੁਰਸ ਟੈਕਸਟ ਦਾ ਚੇਂਜਲੌਗ ਰੱਖੋ, ਅਤੇ ਹਰ ਲੋਕੇਲ ਲਈ ਅਨੁਵਾਦ ਸਥਿਤੀ ਟਰੈਕ ਕਰੋ। ਇੱਕ ਹਲਕੀ ਨਿਯਮ—"ਸੋਰਸ ਟੈਕਸਟ ਬਿਨਾਂ ਟਿਕਟ ਦੇ ਨਾ ਬਦਲੋ"—ਭਾਸ਼ਾਵੀਂ ਸਿੰਕ ਰੱਖਣ ਵਿੱਚ ਘੱਟ ਗੜਬੜ ਕਰਦਾ ਹੈ।
AI ਬਹੁਤ ਸਾਰਾ ਦੁਹਰਾਉਂਦਾ ਕੰਮ ਘਟਾ ਸਕਦਾ ਹੈ—ਪਰ ਸਿਰਫ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਸਹਾਇਕ ਮੰਨ ਕੇ ਵਰਤੋਂ, ਹੁਕਮਰਾਨ ਨਾਂ ਬਣਾ ਕੇ। ਉਦੇਸ਼ ਤੇਜ਼ ਇਤਰੈਸ਼ਨ ਹੈ ਬਿਨਾਂ ਭਾਸ਼ਾ/ਖੇਤਰ/ਸਰਫੇਸ 'ਤੇ ਗੁਣਵੱਤਾ ਟੱਲ ਜਾਣ ਦੇ।
ਜੇ ਤੁਸੀਂ ਨਵੇਂ ਸਤਹ ਤੇਜ਼ੀ ਨਾਲ ਬਿਲਡ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ vibe-coding ਵਰਕਫਲੋ ਮਦਦਗਾਰ ਹੋ ਸਕਦੀ ਹੈ: मंच ਜਿਵੇਂ Koder.ai ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਰਾਹੀਂ ਐਪ ਫਲੋ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦੇ ਹਨ, ਫਿਰ ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ, ਰੂਟਿੰਗ ਅਤੇ ਖੇਤਰੀ ਨਿਯਮਾਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਦੁਹਰਾਉਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਫਿਰ ਵੀ ਉਹੀ ਹੈ: ਲੋਕੇਲ/ਖੇਤਰ ਦੇ ਫੈਸਲੇ ਸਪਸ਼ਟ ਰੱਖੋ, ਫਿਰ ਰੁਟੀਨ-ਕਾਮ ਆਟੋਮੇਟ ਕਰੋ।
ਸਰਵੇ-ਪੱਧਰ ਅਨੁਵਾਦ ਡਰਾਫਟ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੈ। ਆਪਣੀ AI ਟੂਲ ਨੂੰ ਆਪਣੀ ਗਲੋਸਰੀ (ਮੰਨਿਆ ਗਿਆ ਟਰਮੀਨ, ਪ੍ਰੋਡਕਟ ਨਾਮ, ਕਾਨੂੰਨੀ ਫਰੇਜ਼) ਅਤੇ ਟੋਨ ਗਾਈਡ (ਫਾਰਮਲ vs ਦੋਸਤਾਨਾ, "ਤੁਸੀਂ" vs "ਅਸੀਂ", ਵਿਰਾਮ ਲਾਗੂ ਕਰਨ ਦੇ ਨਿਯਮ) ਦਿਓ। ਇਸ ਤਰ੍ਹਾਂ AI ਪਹਿਲਾ-ਪਾਸ ਅਨੁਵਾਦ ਤਿਆਰ ਕਰਕੇ ਤੇਜ਼ ਸਮੀਖਿਆ ਯੋਗ ਨਤੀਜੇ ਦੇ ਸਕਦਾ ਹੈ।
AI ਇਹ ਵੀ ਵਧੀਆ ਹੈ ਕਿ ਸਮੱਸਿਆਵਾਂ ਨਿਕਲ ਕੇ ਦਿਖਾ ਸਕੇ:
{name} ਗੁੱਮ ਹੋਣਾ)ਅਖੀਰਕਾਰ, AI ਖੇਤਰ-ਉਪਯੋਗ ਵੈਰੀਐਂਟ ਸੁਝਾ ਸਕਦਾ ਹੈ — ਉਦਾਹਰਨ ਲਈ en-US ਵर्सਸ en-GB ("Zip code" vs "Postcode") — ਪਰ ਇਨ੍ਹਾਂ ਨੂੰ ਸੁਝਾਵਾਂ ਵਜੋਂ ਲਓ, ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ ਬਦਲਣ ਨਹੀਂ।
ਕੁਝ ਸਮੱਗਰੀ ਉੱਚ-ਖਤਰੇ ਵਾਲੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ ਦੇ ਬਿਨਾਂ ਨਹੀਂ ਜਾ ਸਕਦੀ:
ਪ੍ਰਯੋਗਿਕ ਗਾਰਡਰੇਲ: AI ਡਰਾਫਟ ਕਰੇ, ਉੱਚ-ਖਤਰੇ ਵਾਲੀ ਸਾਮਗਰੀ ਲਈ ਮਨੁੱਖ ਮਨਜ਼ੂਰ ਕਰੇ। ਆਪਣੇ ਵਰਕਫਲੋ ਵਿੱਚ ਮਨਜ਼ੂਰੀ ਸਪੱਸ਼ਟ ਰੱਖੋ (ਉਦਾਹਰਨ: ਪ੍ਰਤੀ-ਸਤਰ ਜਾਂ ਪ੍ਰਤੀ-ਪੇਜ "reviewed" ਸਥਿਤੀ) ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ ਰਿਹੈ ਅਤੇ ਸੁਰੱਖਿਅਤ ਦੋਹਾਂ ਹੋ।
ਇਕਸਾਰਤਾ ਉਹ ਹੈ ਜੋ ਇੱਕ ਬਹੁਭਾਸ਼ੀ ਐਪ ਨੂੰ "ਦੇਸੀ" ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਨਾ ਕਿ ਕੇਵਲ ਅਨੁਵਾਦਿਤ। ਉਪਭੋਗਤਾ ਧਿਆਨ ਦਿੰਦੇ ਹਨ ਜਦ ਇੱਕੋ ਹੀ ਬਟਨ ਇੱਕ ਜਗ੍ਹਾ "Checkout" ਅਤੇ ਦੂਜੇ 'ਤੇ "Pay" ਹੋਵੇ, ਜਾਂ ਸਹਾਇਤਾ ਲੇਖ ਆਲੱਗ-ਆਲੱਗ ਟੋਨ ਵਰਤ ਰਹੇ ਹੋਣ।
ਟਰਮੀਨ ("workspace", "seat", "invoice"), ਕਾਨੂੰਨੀ ਫਰੇਜ਼ ਅਤੇ ਸਹਾਇਤਾ ਸ਼ਬਦਾਵਲੀ ਦੀ ਗਲੋਸਰੀ ਬਣਾਓ। ਪਰਿਭਾਸ਼ਾਵਾਂ, ਮਨਜ਼ੂਰ ਕੀਤੀਆਂ ਅਨੁਵਾਦਾਂ, ਅਤੇ ਨੋਟਸ ਸ਼ਾਮਲ ਕਰੋ ਜਿਵੇਂ "ਬਰਾਂਡ ਨਾਂ ਅਨੁਵਾਦ ਨਾ ਕਰੋ"।
ਗਲੋਸਰੀ ਹਰ ਲਿਖਣ ਵਾਲੇ ਲਈ ਪਹੁੰਚਯੋਗ ਰੱਖੋ: ਪ੍ਰੋਡਕਟ, ਮਾਰਕੇਟਿੰਗ, ਲੀਗਲ ਅਤੇ ਸਹਾਇਤਾ। ਜਦੋਂ ਕਿਸੇ ਸ਼ਬਦ ਨੂੰ ਬਦਲਾ ਜਾਂਦਾ ਹੈ ("Projects" → "Workspaces"), ਪਹਿਲਾਂ ਗਲੋਸਰੀ ਅੱਪਡੇਟ ਕਰੋ, ਫਿਰ ਅਨੁਵਾਦ।
ਟੋਨ ਸਾਰਥਕ ਨਹੀਂ ਹੁੰਦਾ। ਪ੍ਰਤੀ-ਭਾਸ਼ਾ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਫਾਰਮਲ ਜਾਂ ਅਨੌਪਚਾਰਿਕ ਪਤਾ ਵਰਤੋਂਗੇ, ਵਾਕ ਦੀ ਲੰਬਾਈ ਪ੍ਰਾਥਮਿਕਤਾ, ਵਿਸੰਗਤ ਲਿਪਿ-ਚਿੰਨ੍ਹਾਂ ਅਤੇ ਕਿਵੇਂ ਅੰਗਰੇਜ਼ੀ ਸ਼ਬਦ ਵਰਤੇ ਜਾਣਗੇ।
ਹਰੇਕ ਲੋਕੇਲ ਲਈ ਇੱਕ ਛੋਟੀ ਸਟਾਈਲ ਗਾਈਡ ਲਿਖੋ (ਇੱਕ ਪੰਨਾ ਕਾਫ਼ੀ):
TM ਮਨਜ਼ੂਰ ਕੀਤੀਆਂ ਦੁਹਰਾਈਆਂ ਸਤਰਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਇੱਕੋ ਹੀ ਸੋਰਸ ਟੈਕਸਟ ਲਈ ਇੱਕੋ ਹੀ ਅਨੁਵਾਦ ਆਵੇ। ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਕੀਮਤੀ ਹੈ:
TM ਲਾਗਤ ਅਤੇ ਸਮੀਖਿਆ ਸਮਾਂ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ AI ਨਤੀਜਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਫੈਸਲਿਆں ਨਾਲ ਸੰਗਤ ਰੱਖਦੀ ਹੈ।
"Close" ਇੱਕ ਕਿਰਿਆ ਹੈ (ਮੋਡਲ ਬੰਦ ਕਰੋ) ਜਾਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ਣ (ਨੇੜੇ)? ਸੰਦਰਭ ਸਕਰੀਨਸ਼ਾਟ, ਅੱਖਰ ਸੀਮਾਵਾਂ, UI ਦਾ ਸਥਾਨ, ਅਤੇ ਡਿਵੈਲਪਰ ਨੋਟਸ ਦੇ ਕੇ ਦਿਓ। ਸਢੰਚਿਤ ਕੁੰਜੀਆਂ ਅਤੇ ਮੈਟਾਡੇਟਾ ਪছੰਦ ਕਰੋ — ਅਨੁਵਾਦਕ ਅਤੇ AI ਦੋਹਾਂ ਹੀ ਇਰਾਦਾ ਜਾਣਨ 'ਤੇ ਬਿਹਤਰ ਨਤੀਜੇ ਦੇਂਦੇ ਹਨ।
ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਬੱਗ ਛੋਟੇ ਲੱਗਦੇ ਹਨ ਪਰ ਗਾਹਕ ਮੱਤ 'ਤੇ ਵੱਡੇ ਪ੍ਰਭਾਵ ਛੱਡ ਸਕਦੇ ਹਨ: ਗਲਤ ਭਾਸ਼ਾ ਵਿੱਚ ਚੈੱਕਆਉਟ ਈਮੇਲ, ਗਲਤ ਤਾਰੀਖ ਪਾਰਸ ਹੋਣਾ, ਜਾਂ ਮੋਬਾਈਲ 'ਤੇ ਕਟ ਜਾਂਦਾ ਲੇਬਲ। ਲਕਸ਼ ਯਹ ਨਹੀਂ ਕਿ ਪਹਿਲੇ ਦਿਨ ਉੱਤੇ ਪੂਰੀ ਕਵਰੇਜ ਹੋਵੇ—ਇਹ ਟੈਸਟਿੰਗ ਤਰੀਕਾ ਹੈ ਜੋ ਸਭ ਤੋਂ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਕਾਰਾ automática ਰੂਪ ਵਿੱਚ ਫੜਦਾ ਹੈ, ਅਤੇ ਮਨੁੱਖੀ QA ਨੂੰ ਉਹਨਾਂ ਖੇਤਰਾਂ ਲਈ ਰੱਖਦਾ ਹੈ ਜਿੱਥੇ ਖੇਤਰੀ ਨਿਯਮ ਵਧੇਰੇ ਮਹੱਤਵ ਰੱਖਦੇ ਹਨ।
ਟੈਕਸਟ ਵਰਧਨ ਅਤੇ ਲਿਪੀ ਫ਼ਰਕ ਲੇਆਊਟ ਤੋੜਨ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹਨ:
ਇੱਕ ਹਲਕੀ "ਪਸੂਡੋ-ਲੋਕੇਲ" (ਅਤਿ-ਲੰਬੇ ਸਤਰ + ਅਕਸੈਂਟ ਚਰਿੱਤਰ) CI ਗੇਟ ਵਜੋਂ ਵਧੀਆ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਸਲੀ ਅਨੁਵਾਦਾਂ ਬਿਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਲੱਭ ਲੈਂਦਾ ਹੈ।
ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਸਿਰਫ ਕਾਪੀ ਨਹੀਂ — ਇਹ ਪਾਰਸਿੰਗ ਅਤੇ ਆਰਡਰਿੰਗ ਨੂੰ बदल ਸਕਦੀ ਹੈ:
PR 'ਤੇ ਚਲਨ ਵਾਲੇ ਤੇਜ਼ ਚੈੱਕ ਸ਼ਾਮਲ ਕਰੋ:
{count} ਇੱਕ ਭਾਸ਼ਾ 'ਚ ਹੈ ਪਰ ਦੂਜੇ 'ਚ ਨਹੀਂ)ਇਹ ਸਸਤੀ ਸੁਰੱਖਿਆਆਂ ਹਨ ਜੋ "ਕੇਵਲ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਕੰਮ ਕਰਦਾ" ਰਿਗ੍ਰੈਸ਼ਨ ਰੋਕਦੀਆਂ ਹਨ।
ਉਹ ਸਾਰੀਆਂ ਪ੍ਰੋਸੀਜ਼ ਜਿਨ੍ਹਾਂ 'ਤੇ ਲੋਕਲ ਨਿਯਮ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਲਈ ਟਾਰਗਿਟਡ ਪਾਸ ਰੱਖੋ:
ਹਰੇਕ ਖੇਤਰ ਲਈ ਇੱਕ ਛੋਟੀ, ਦੁਹਰਾਏ ਯੋਗ ਚੈਕਲਿਸਟ ਰੱਖੋ ਅਤੇ ਰੋਲਆਉਟ ਜਾਂ ਮੁੱਲ/ਕੰਪਲਾਇੰਸ-ਸਬੰਧੀ ਕੋਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਚਲਾਓ।
ਇੱਕ ਬਹੁਭਾਸ਼ੀ, ਬਹੁ-ਖੇਤਰੀ ਐਪ ਸਮਰੱਥਾ ਦੇਖਣ 'ਚ "ਠੀਕ" ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਇੱਕ ਲੋਕੇਲ ਜਾਂ ਖੇਤਰ ਲਈ ਖਰਾਬ ਹੋ ਸਕਦੀ ਹੈ। ਮਾਨੀਟਰਿੰਗ ਨੂੰ ਲੋਕੇਲ (ਭਾਸ਼ਾ + ਫਾਰਮੇਟਿੰਗ ਨਿਯਮ) ਅਤੇ ਖੇਤਰ (ਜਿੱਥੇ ਟ੍ਰੈਫਿਕ ਸਰਵ ਹੋ ਰਿਹਾ ਹੈ, ਡੇਟਾ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸ ਹੋਂਦੇ ਹਨ) ਅਨੁਸਾਰ ਸਲਾਈਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸਮੱਸਿਆਵਾਂ ਨੋਟਿਸ ਕਰੋ।
ਮੁੱਖ ਉਤਪਾਦ ਮੈਟਰਿਕਸ ਨੂੰ ਲੋਕੇਲ/ਖੇਤਰ ਟੈਗ ਨਾਲ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰੋ: ਕਨਵਰਜ਼ਨ ਅਤੇ ਚੈੱਕਆਉਟ ਪੂਰਾ ਹੋਣਾ, ਸਾਈਨ-ਅਪ ਡ੍ਰਾਪ-ਆਫ਼, ਖੋਜ ਸਫਲਤਾ, ਅਤੇ ਮੁੱਖ ਫੀਚਰ ਗ੍ਰਹਿਣ। ਇਨ੍ਹਾਂ ਨੂੰ ਟੈਕਨੀਕੀ ਸਿਗਨਲ ਜਿਵੇਂ ਐਰਰ ਰੇਟ ਅਤੇ ਲੇਟੈਂਸੀ ਨਾਲ ਜੋੜੋ। ਇੱਕ ਛੋਟਾ “ਗਲੋਬਲ ਵਿਊ” ਅਤੇ ਕੁਝ ਉਚ-ਤਰਜੀਹ ਸੈਗਮੈਂਟ (ਟੌਪ ਲੋਕੇਲ, ਨਵਾਂ ਖੇਤਰ, ਸਭ ਤੋਂ ਵੱਧ ਆਮਦਨੀ ਵਾਲੇ ਬਾਜ਼ਾਰ) ਰੱਖੋ; ਬਾਕੀ ਡ੍ਰਿੱਲ-ਡਾਊਨ ਲਈ ਛੱਡੋ।
ਅਨੁਵਾਦ ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਾਇਲੇਂਟ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ। ਲਾਗ ਅਤੇ ਟ੍ਰੈਂਡ ਕਰੋ:
ਕਿਸੇ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਫੌਲਬੈਕ ਵਰਤੋਂ ਵਿੱਚ spike ਇੱਕ ਤਗੜਾ ਸੰਕੇਤ ਹੈ ਕਿ ਬਿਲਡ ਨਵੀਨਤਮ ਲੋਕੇਲ ਬੰਡਲ ਬਿਨਾਂ ਅਪਡੇਟ ਸ਼ਿਪ ਹੋਿਆ।
ਰੂਟਿੰਗ ਅਤੇ CDN ਅਨੋਮਾਲੀਜ਼ (ਉਦਾਹਰਨ: 404/503 ਵਧਣਾ, ਓਰੀਜਿਨ ਟਾਈਮਆਉਟ) ਲਈ ਖੇਤਰ-ਮਸ਼ੀਨ ਅਲਰਟ ਸੈੱਟ ਕਰੋ, ਨਾਲ ਹੀ ਪ੍ਰਦਾਤਾ-ਨਿਰਧਾਰਤ ਫੇਲਿਯਰ ਜਿਵੇਂ ਭੁਗਤਾਨ ਡਿਕਲਾਈਨ ਆਦਿ। ਅਲਰਟਸ ਕਾਰਵਾਈਯੋਗ ਬਣਾਉ: ਪ੍ਰਭਾਵਿਤ ਖੇਤਰ, ਲੋਕੇਲ ਅਤੇ ਆਖਰੀ ਡਿਪਲੌਇ/ਫੀਚਰ ਫਲੈਗ ਬਦਲਾਅ ਸ਼ਾਮਲ ਕਰੋ।
ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਲੋਕੇਲ/ਖੇਤਰ ਅਧਾਰ 'ਤੇ ਟੈਗ ਕਰੋ ਅਤੇ ਸਹੀ ਕਿਊ ਨੂੰ ਰੂਟ ਕਰੋ। ਹਰੇਕ ਮਾਰਕੀਟ ਲਈ ਹਲਕਾ in-app ਪ੍ਰੈਪਟ ("ਕੀ ਇਹ ਪੰਨਾ ਸਪਸ਼ਟ ਸੀ?") ਲੋਕਲਾਈਜ਼ਡ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਨੁਵਾਦ, ਟਰਮੀਨੋਲੋਜੀ ਜਾਂ ਲੋਕਲ ਉਮੀਦਾਂ ਕਾਰਨ ਹੋ ਰਹੀ ਗੁੰਝਲ ਨੂੰ ਰਿਪੋਰਟ ਕਰ ਸਕੋ—ਚਰਨ ਤੋਂ ਪਹਿਲਾਂ।
ਇੱਕ ਬਹੁਭਾਸ਼ੀ, ਬਹੁ-ਖੇਤਰੀ ਐਪ ਕਦੇ ਵੀ "ਮੁਕੰਮਲ" ਨਹੀਂ ਹੁੰਦੀ—ਇਹ ਇਕ ਉਤਪਾਦ ਹੈ ਜੋ ਸਿਖਦਾ ਰਹਿੰਦਾ ਹੈ। ਰੋਲਆਉਟ ਦਾ ਲਕਸ਼ ਰਿਸਕ ਘਟਾਉਣਾ ਹੈ: ਕੁਝ ਛੋਟਾ ਸ਼ਿਪ ਕਰੋ ਜੋ ਤੁਸੀਂ ਨਿਗਰਾਨੀ ਕਰ ਸਕੋ, ਫਿਰ ਭਰੋਸੇ ਨਾਲ ਵਧਾਓ।
ਇੱਕ "ਪਤਲੀ ਸਲਾਈਸ" ਲਾਂਚ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: 1 ਭਾਸ਼ਾ + 1 ਵਾਧੂ ਖੇਤਰ। ਉਸ ਸਲਾਈਸ ਨੂੰ ਪੂਰਾ ਯਾਤਰਾ ਸ਼ਾਮਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ (ਸਾਇਨ-ਅਪ, ਮੁੱਖ ਫਲੋ, ਸਹਾਇਤਾ ਟਚਪੌਇੰਟ ਅਤੇ ਬਿਲਿੰਗ ਜੇ ਲਾਗੂ ਹੋਵੇ)। ਤੁਸੀਂ-specs ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟਾਂ ਨਾਲ ਨਾ ਦਿਖ ਰਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਜਿਵੇਂ ਕਿ ਤਾਰੀਖ ਫਾਰਮੇਟ, ਪਤਾ ਫੀਲਡ, ਐਰਰ ਸੁਨੇਹੇ ਅਤੇ ਕਾਨੂੰਨੀ ਕਾਪੀ ਦਿਖਦੇ ਹੋਵੋਗੇ।
ਹਰ ਲੋਕੇਲ/ਖੇਤਰ ਜੋੜੇ ਨੂੰ ਇੱਕ ਨਿਯੰਤਰਿਤ ਰਿਲੀਜ਼ ਯੂਨਿਟ ਮੰਨੋ। ਲੋਕੇਲ/ਖੇਤਰ ਨਾਲ ਫੀਚਰ ਫਲੈਗ ਤੁਹਾਨੂੰ ਇਹ ਯੋਗਤਾ ਦਿੰਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਫਲੈਗ ਵਰਤਦੇ ਹੋ, ਤਾਂ locale, country, ਅਤੇ ਜਦ ਲੋੜ ਹੋਵੇ currency ਲਈ ਟਾਰਗੇਟਿੰਗ ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ।
ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਵਿਗੜਨ ਤੋਂ ਬਚਾਉਣ ਲਈ ਹਲਕੀ-ਭਾਰ ਰੱਖ-ਰਖਾਅ ਲੂਪ ਬਣਾਓ:
ਅਗਲੇ ਕਦਮ: ਇਸ ਚੈਕਲਿਸਟ ਨੂੰ ਇੱਕ ਰਿਲੀਜ਼ ਪਲੇਬੁੱਕ ਵਿੱਚ ਬਦਲੋ ਜੋ ਤੱਕਨੀਕੀ ਟੀਮ ਵਰਤੇ, ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਰੋਡਮੈਪ ਦੇ ਨੇੜੇ ਰੱਖੋ (ਜਾਂ ਆਪਣੀ ਇੰਟਰਨਲ ਡੌਕਸ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ)। ਜੇ ਤੁਸੀਂ ਹੋਰ ਵਰਕਫਲੋ-ਰਹਿਣ-ਸਲਾਹਾਂ ਚਾਹੁੰਦੇ ਹੋ, /blog ਦੇਖੋ।
ਬਹੁਭਾਸ਼ੀ ਐਪ ਭਾਸ਼ਾ ਦੇ ਤਰੀਕੇ ਨੂੰ ਬਦਲਦੀ ਹੈ (UI ਸਤਰਾਂ, ਈਮੇਲ, ਦਸਤਾਵੇਜ਼) ਤਾਂ ਜੋ ਉਹ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਕੁਦਰਤੀ ਲੱਗਣ। ਬਹੁ-ਖੇਤਰੀ ਐਪ ਉਹ ਨਿਯਮ ਬਦਲਦੀ ਹੈ ਜੋ ਗਾਹਕ ਨੂੰ ਸਰਵ ਕੀਤਾ ਜਾਣਦਾ ਹੈ—ਮੁਦਰਾ, ਟੈਕਸ, ਉਪਲਬਧਤਾ, ਅਨੁਕੂਲਤਾ ਅਤੇ ਡੇਟਾ ਰਿਹਾਇਸ਼। ਕਈ ਉਤਪਾਦਾਂ ਨੂੰ ਦੋਹਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਮੁਸ਼ਕਲ ਗੱਲ ਇਹ ਹੈ ਕਿ ਭਾਸ਼ਾ ਨੂੰ ਖੇਤਰੀ ਵਪਾਰਕ ਲੋਜਿਕ ਤੋਂ ਅਲੱਗ ਰੱਖਣਾ।
ਸਰਲ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਉਹ_combination_ ਦਰਸਾਏ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸਹਿਯੋਗ ਦੇ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ: en-GB + GB + GBP). ਵੱਡੇ ਨਿਯਮ ਬਦਲਾਅਾਂ ਲਈ ਨੋਟਸ ਸ਼ਾਮਲ ਕਰੋ (ਟੈਕਸ ਸ਼ਾਮਲ/ਜੋੜਿਆ, કਾਨੂੰਨੀ ਪੇਜਾਂ ਦੇ ਵੈਰੀਅੰਟ, ਲੋੜੀਂਦੇ ਭੁਗਤਾਨ ਢੰਗ). ਇਸ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸਕੋਪ ਕਾਨਟ੍ਰੈਕਟ ਵਜੋਂ ਰੱਖੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਰੂਟਿੰਗ, ਫਾਰਮੇਟਿੰਗ, ਭੁਗਤਾਨ ਅਤੇ QA ਨਿਰਭਰ ਕਰਨ।
ਜਦੋਂ ਖੇਤਰੀ ਫਰਕ ਮਹੱਤਵਪੂਰਨ ਹੋ (ਹਜਮ/ਸਪੈੱਲਿੰਗ, ਕਾਨੂੰਨੀ ਟੈਕਸਟ, ਸਪੋਰਟ ਆਚਰਨ, ਮੁੱਲ ਨਿਯਮ), ਤਾਂ language-region ਪਸੰਦ ਕਰੋ (ਜਿਵੇਂ en-US ਬਨਾਮ en-GB, pt-BR ਬਨਾਮ pt-PT). ਜੇ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਸ਼ਚਤ ਹੋ ਕਿ ਅੰਤਰ ਘੱਟ ਹੈ, ਤਾਂ ਹੀ ਸਿਰਫ਼ ਭਾਸ਼ਾ (fr) ਵਰਤੋਂ; ਬਾਅਦ ਵਿੱਚ ਵੰਡਣਾ ਵਿਵਸਥਾ-ਭੰਗ ਵਾਲਾ ਹੋ ਸਕਦਾ ਹੈ।
fr-CA → fr → en.ਇਹ ਨਿਯਮ ਲਿਖੋ ਤਾਂ ਜੋ ਇੰਜੀਨੀਅਰ, QA ਅਤੇ ਸਹਾਇਤਾ ਇਕੋ ਹੀ ਬਰਤਾਅ ਦੀ ਉਮੀਦ ਕਰਨ।
ਇਹ ਸਿਰਫ UI ਸਤਰ ਨਹੀਂ — ਲੋਕਲਾਈਜ਼ ਕਰਨ ਲਈ:
ਅਤੇ ਇਹ ਵੀ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ “ਖੇਤਰ” ਮੁੱਲ ਕਿੱਥੋਂ ਆਇਆ (ਅਕਾਊਂਟ ਸੈਟਿੰਗ, ਯੂਜ਼ਰ ਚੋਣ, GeoIP ਸੁਝਾਅ) ਤਾਂ ਜੋ ਫਾਰਮੇਟਿੰਗ ਬੈਕਐਂਡ ਸੇਵਾਵਾਂ ਨਾਲ ਮੇਲ ਖਾਏ।
ਪਰਿਮਾਣੂ کے طور پر ਰੂਟਿੰਗ ਪੈਟਰਨ ਨੂੰ ਜਲਦੀ ਚੁਣੋ — ਬਦਲਣ ਨਾਲ SEO, ਸ਼ੇਅਰਬਲ ਲਿੰਕ ਅਤੇ ਹੋਰ ਪ੍ਰਭਾਵਤ ਹੁੰਦੇ ਹਨ। ਆਮ ਵਿਕਲਪ:
/en-us/... (ਸਰਲ, CDN-ਦੋਸਤ)us.example.com (ਸਪਸ਼ਟ ਵੰਡ, DNS/ਸਰਟੀਫਿਕੇਟ ਜ਼ਰੂਰਤ)ਫਰੰਟ-ਐਂਡ ਰੂਟਿੰਗ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਕੀ ਵੇਖਦੇ ਹਨ; ਪਰ ਖੇਤਰੀ ਰੂਟਿੰਗ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਬੇਨਤੀਆਂ ਕਿੱਥੇ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ: ਇੱਕ ਹੀ “region” ਮੁੱਲ ਨੂੰ ਬੇਨਤੀਆਂ ਰਾਹੀਂ ਪਾਸ ਕਰੋ (ਹੈਡਰ, ਟੋਕਨ ਦਾਅਵਾ, ਜਾਂ ਸੈਸ਼ਨ) ਅਤੇ ਇਸਦੇ ਆਧਾਰ 'ਤੇ ਬੈਕਐਂਡ ਐਂਡਪੌਇੰਟ ਅਤੇ ਡੇਟਾਬੇਸ ਚੁਣੋ (ਉਦਾਹਰਨ: AU ਲਈ AU ਪ੍ਰਾਇਸਿੰਗ ਸੇਵਾ, AU ਟੈਕਸ ਨਿਯਮ)।
ਭਾਸ਼ਾ ਤੋਂ ਖੇਤਰ ਨੂੰ ਨਹੀਂ ਨਿਰਧਾਰਤ ਕਰਨਾ; ਇਹ ਦੋ ਵੱਖ-ਵੱਖ आयਾਮ ਹਨ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਇਕੱਤਰ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਜਾਣਕਾਰੀ ਅਤੇ ਉਹ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ, ਇਹ ਨਕਸ਼ਾ ਬਣਾਓ। ਆਮ 'ਸੰਵੇਦਨਸ਼ੀਲ' ਸ਼੍ਰੇਣੀਆਂ:
ਤੇ ਇਹ ਨਕਸ਼ਾ ਦੀਪਕ ਕਰੋ ਕਿ ਇਹ ਡੇਟਾ ਪ੍ਰਾਇਮਰੀ DB, ਲੌਗ, ਬੈਕਅੱਪ, ਐਨਾਲਿਟਿਕਸ, ਖੋਜ ਇੰਡੈਕਸ ਅਤੇ ਤੀਜੀ-ਪੱਖੀ ਸੇਵਾਵਾਂ ਵਿੱਚ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ। ਬਹੁਤ ਵਾਰੀ ਲੋਗ ਅਤੇ ਬੈਕਅੱਪ ਰਿਹਾਇਸ਼ ਨীতੀਆਂ ਨੂੰ ਉਲੰਘਣ ਕਰ ਸਕਦੇ ਹਨ।
ਖੇਤਰੀ ਮੁਲਾਂਕਣ ਲਈ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਰਸਤੇ ਹੋ ਸਕਦੇ ਹਨ: ਰੀਜਨ-ਅਧਾਰਿਤ ਡੈਟਾਬੇਸ (ਮਜ਼ਬੂਤ ਅਲੱਗੋ), ਇਕ ਸਾਂਝੇ ਸਿਸਟਮ ਵਿੱਚ ਪਾਰਟੀਸ਼ਨ (ਕੋਨਟਰੋਲਡ ਅਲੱਗੋ), ਜਾਂ ਏਨਕ੍ਰਿਪਸ਼ਨ ਸੀਮੇਟਰੀਆਂ ਜੋ ਰੀਜਨ-ਵਿਸ਼ੇਸ਼ ਚਾਵੀਆਂ ਰੱਖਦੀਆਂ ਹਨ। ਹਰ ਇਕ ਦੇ ਫਾਇਦੇ/ਖਰਚ ਹਨ; ਨੀਤੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕ੍ਰਿਤ ਕਰੋ ਅਤੇ ਕਾਨੂੰਨੀ ਸਲਾਹ ਲਵੋ।
ਖੇਤਰ-ਵਿਸ਼ੇਸ਼ ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ (ਭੁਗਤਾਨ ਢੰਗ, ਟੈਕਸ ਸੁਭਾਵ, ਇਨਵਾਇਸ ਫੀਲਡ) ਲਈ ਪਹਿਲਾਂ ਵਿਵਲਿਸਟ ਬਣਾਓ ਅਤੇ ਪ੍ਰਤਿਉੱਤਰ (ਉਦਾਹਰਨ: ਪ੍ਰੋਡੈਕਟ, ਫਾਇਨੈਂਸ, ਲੀਗਲ) ਨੂੰ ਮਾਲਕ ਬਣਾਓ। ਇਹ ਇਨਵੈੰਡਰੀ ਭੁਗਤਾਨ, ਟੈਕਸ ਅਤੇ ਇਨਵਾਇਸਿੰਗ ਦੀ ਸ਼ੁੱਧਤਾ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ।
?lang=fr®ion=CAਅਧਿਕਤਮ ਟੀਮਾਂ ਲਈ ਪਾਥ ਪ੍ਰੀਫਿਕਸ ਡਿਫੌਲਟ ਹੈ।
SEO ਲਈ ਯੋਜਨਾ: ਹਰ ਲੋਕੇਲ/ਖੇਤਰ URL ਲਈ ਸਕੇਲ-ਸੰਬੰਧਤ ਕੈਨੋਨਿਕ ਅਤੇ hreflang ਸੈਟ ਤੇ x-default।