29 ਨਵੰ 2025·8 ਮਿੰਟ
ਚੈਟ-ਤਿਆਰ ਐਪਾਂ ਲਈ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ
ਚੈਟ-ਤਿਆਰ ਐਪਾਂ ਲਈ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ: ਸਥਿਰ ਸਟਰਿੰਗ ਕੁੰਜੀਆਂ, ਬਹੁਵਚਨ ਨਿਯਮ ਅਤੇ ਇੱਕ ਏਨਾ ਅਨੁਵਾਦ ਵਰਕਫਲੋ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਇਕਸਾਰ ਰਹੇ।
ਪਹਿਲਾਂ ਕੀ ਟੁੱਟਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਜੋੜਦੇ ਹੋ
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਟੁੱਟਣ ਵਾਲੀ ਗੱਲ ਕੋਡ ਨਹੀਂ ਹੁੰਦੀ। ਉਹ ਸ਼ਬਦ ਹੁੰਦੇ ਹਨ।
ਚੈਟ-ਤਿਆਰ ਐਪਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ “Add a button that says Save”, UI ਬਣ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਅੱਗੇ ਨਿੱਕਲ ਜਾਂਦੇ ਹੋ। ਹਫ਼ਤੇ ਬਾਅਦ ਤੁਸੀਂ ਸਪੇਨੀਸ਼ ਅਤੇ ਜਰਮਨ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਪata ਲੱਗਦਾ ਹੈ ਉਹ "ਅਸਥਾਈ" ਲੇਬਲ ਸਕ੍ਰੀਨਾਂ, ਕੰਪੋਨੈਂਟਸ, ਈਮੇਲਾਂ ਅਤੇ ਐਰਰ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਫੈਲ ਚੁੱਕੇ ਹਨ।
ਲਿਖਤ (copy) ਬਦਲਾਅ ਕੋਡ ਬਦਲਾਅ ਨਾਲੋਂ ਵੱਧ ਹੋਂਦੇ ਹਨ। ਉਤਪਾਦ ਦੇ ਨਾਮ ਬਦਲਦੇ ਹਨ, ਕਾਨੂੰਨੀ ਲਿਖਤ ਤਬਦੀਲ ਹੁੰਦੀ ਹੈ, ਔਨਬੋਰਡਿੰਗ ਦੁਬਾਰਾ ਲਿਖੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸਹਾਇਤਾ ਵੱਲੋਂ ਸਾਫ਼-ਸੁਥਰੇ ਐਰਰ ਸੁਨੇਹਿਆਂ ਦੀ ਮੰਗ ਆਉਂਦੀ ਹੈ। ਜੇ ਲਿਖਤ ਸਿੱਧਾ UI ਕੋਡ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਹਰ ਛੋਟੀ ਸੂਧ ਨੂੰ ਰਿਸਕੀ ਰਿਲੀਜ਼ ਬਣਾਉਣੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਉਹ ਥਾਵਾਂ ਗੁਆਂਢੇ ਹੋ ਜਾਂਦੇ ਹੋ ਜਿੱਥੇ ਇੱਕੋ ਹੀ ਵਿਚਾਰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਲਿਖਿਆ ਗਿਆ ਹੈ।
ਇੱਥੇ ਉਹ ਸ਼ੁਰੂਆਤੀ ਲਕੜੀਆਂ ਹਨ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਤੁਸੀਂ ਅਨੁਵਾਦ ਦੀ ਮਿਆਦ ਗਠ ਰਹੇ ਹੋ:
- ਇੱਕ ਸਕ੍ਰੀਨ 'ਤੇ ਮਿਲੀ-ਜੁਲੀ ਭਾਸ਼ਾਵਾਂ (ਕੁਝ ਸਤਰਾਂ ਅਨੁਵਾਦ ਕੀਤੀਆਂ, ਹੋਰ ਅਜੇ ਵੀ ਅੰਗਰੇਜ਼ੀ).
- ਇੱਕੋ ਲੇਬਲ ਦੀ ਤਬਦੀਲੀ ਨਾਲ ਨਕਲਾਂ ("Sign up", "Sign Up", "Create account").
- ਜਦੋਂ ਲਿਖਤ ਲੰਮੀ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਲੇਆਉਟ ਟੁਟਦੇ ਹਨ (ਬਟਨ overflow ਕਰਦੇ, ਸਿਰਲੇਖ ਠੀਕ ਨਾਲ wrap ਨਹੀਂ ਹੁੰਦੇ).
- ਮੋਬਾਈਲ ਅਤੇ ਵੈੱਬ ਵਿੱਚ ਫਰਕ ਆ ਜਾਂਦਾ ਹੈ (ਇੱਕੋ ਕਾਰਵਾਈ ਲਈ ਵੱਖਰੇ ਸ਼ਬਦ).
- ਸਪੋਰਟ ਸਮੱਗਰੀ ਅਤੇ ਸਿਸਟਮ ਸੁਨੇਹੇ UI ਦੇ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦੇ ਹਨ.
ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਣ: ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਇੱਕ ਸਾਦਾ CRM ਬਣਾਉਂਦੇ ਹੋ। ਵੈੱਬ ਐਪ ਕਹਿੰਦੀ ਹੈ “Deal stage”, ਮੋਬਾਈਲ ਕਹਿੰਦੀ ਹੈ “Pipeline step”, ਅਤੇ ਇੱਕ ਐਰਰ ਟੋਸਟ ਕਹਿੰਦੀ ਹੈ “Invalid status”。ਜੇਕਰ ਤਿੰਨੋ ਦਾ ਅਨੁਵਾਦ ਹੋਵੇ ਵੀ, ਉਪਭੋਗਤਾ ਐਪ ਨੂੰ ਅਸੰਗਤ ਮਹਿਸੂਸ ਕਰਨਗੇ ਕਿਉਂਕਿ ਕੰਸੈਪਟਾਂ ਮਿਲਦੇ-ਜੁਲਦੇ ਨਹੀਂ ਹਨ।
“ਕਾਂਸੀਸਟੈਂਸੀ” ਦਾ ਅਰਥ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਜਗ੍ਹਾ ਇਕੋ ਅੱਖਰ ਹੋਣ। ਇਸਦਾ ਮਤਲਬ ਹੈ:
- ਇੱਕੋ ਕੰਸੈਪਟ ਲਈ ਇੱਕੋ ਕੀ ਅਤੇ ਇੱਕੋ ਅਰਥ ਹੋਵੇ।
- ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਦੋਵਾਂ ਲਈ ਇਕੋ ਸਰੋਤ-ਸੱਚ (source of truth) ਹੋਵੇ।
- ਟੋਨ ਅਤੇ ਟਰਮੀਨਾਲੋਜੀ ਸਥਿਰ ਰਹੇ (ਫਾਰਮਲ ਬਣਾਮ ਕੈਜ਼ੂਅਲ, “customer” ਬਣਾਮ “client”).
- UI ਲੇਆਉਟ ਛੋਟੇ ਜਾਂ ਲੰਮੇ ਵਾਕਾਂ ਨੂੰ ਸਹਿਣ ਦੇ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਜਾਣ।
ਜਦੋਂ ਤੁਸੀਂ ਲਿਖਤ ਨੂੰ ਡਿਕੋਰੇਸ਼ਨ ਨਾ ਮੰਨ ਕੇ ਪ੍ਰੋਡਕਟ ਡੇਟਾ ਵਜੋਂ ਦੇਖੋਗੇ, ਤਾਂ ਭਾਸ਼ਾਵਾਂ ਸ਼ਾਮਲ ਕਰਨਾ ਇਕ ਹੜਤਾਲ ਨਹੀਂ ਰਹਿੰਦਾ ਅਤੇ ਇਹ ਨਿਰਮਾਣ ਦਾ ਰੋਜ਼ਾਨਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਬੁਨਿਆਦੀ ਧਾਰਣਾਵਾਂ ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਲਕੜੀ
Internationalization (i18n) ਉਹ ਕੰਮ ਹੈ ਜੋ ਤੁਸੀਂ ਕਰਦੇ ਹੋ ਤਾਂ ਜੋ ਇੱਕ ਐਪ ਬਿਨਾਂ ਮੁੜ-ਲਿਖਣ ਦੇ ਕਈ ਭਾਸ਼ਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕੇ। Localization (l10n) ਕਿਸੇ ਖ਼ਾਸ ਭਾਸ਼ਾ ਅਤੇ ਖੇਤਰ ਲਈ ਅਸਲੀ ਸਮੱਗਰੀ ਹੈ, ਜਿਵੇਂ French (Canada) ਨਾਲ ਠੀਕ ਸ਼ਬਦ, ਤਾਰੀਖ਼ ਫਾਰਮੇਟ ਅਤੇ ਟੋਨ।
ਇੱਕ ਸਧਾਰਨ ਲਕੜੀ: ਹਰੇਕ ਉਪਭੋਗਤਾ-ਮੁਖੀ ਲਿਖਤ ਇੱਕ ਸਥਿਰ ਕੀ ਤੋਂ ਚੁਣੀ ਜਾਵੇ, ਨਾ ਕਿ ਸਿੱਧਾ UI ਕੋਡ ਵਿੱਚ ਟਾਇਪ ਕੀਤੀ ਜਾਵੇ। ਜੇ ਤੁਸੀਂ ਇਕ ਵਾਕ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ React ਕੰਪੋਨੈਂਟ ਜਾਂ Flutter widget ਖੋਲ੍ਹੇ, ਤਾਂ ਤੁਸੀਂ ਸਹੀ ਰਾਹ 'ਤੇ ਹੋ। ਇਹ ਚੈਟ-ਤਿਆਰ ਐਪਾਂ ਲਈ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ ਦੀ ਮੂਲ ਗੱਲ ਹੈ, ਜਿਥੇ ਚੈਟ ਸੈਸ਼ਨ ਦੌਰਾਨ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹਾਰਡ-ਕੋਡ ਕੀਤੀ ਲਿਖਤ ਅਕਸਰ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਰਿਲੀਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ।
ਉਪਭੋਗਤਾ-ਮੁਖੀ ਲਿਖਤ ਜ਼ਿਆਦਾ ਚੀਜ਼ਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ ਜਿਸਦਾ ਅਣੰਦਾਜ਼ਾ ਬਹੁਤ ਟੀਮਾਂ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਵਿੱਚ ਬਟਨ, ਲੇਬਲ, ਵੈਲਿਡੇਸ਼ਨ ਐਰਰ, ਖਾਲੀ ਸਟੇਟ, ਔਨਬੋਰਡਿੰਗ ਟਿਪਸ, ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਈਮੇਲ, PDF ਐਕਸਪੋਰਟ ਅਤੇ ਕੋਈ ਵੀ ਸੁਨੇਹਾ ਜੋ ਯੂਜ਼ਰ ਵੇਖ ਸਕਦਾ/ਸੁਣ ਸਕਦੀ ਹੈ ਆਉਂਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਅੰਦਰੂਨੀ ਲੌਗ, ਡਾਟਾਬੇਸ ਕਾਲਮ ਨਾਮ, ਐਨਾਲਿਟਿਕਸ ਇਵੈਂਟ ID, ਫੀਚਰ ਫਲੈਗ ਜਾਂ ਅਡਮਿਨ-ਕੇਵਲ ਡਿਬੱਗ ਆਉਟਪੁੱਟ ਨੂੰ ਸ਼ਾਮਲ ਨਹੀਂ ਕਰਦਾ।
ਅਨੁਵਾਦ ਕਿੱਥੇ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ? ਅਮਲੀ ਤੌਰ 'ਤੇ, ਅਕਸਰ ਦੋਹਾਂ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ 'ਚ, ਪਰ ਇੱਕ ਸਾਫ਼ ਹਦਬੰਦੀ ਨਾਲ।
- ਫਰੰਟਐਂਡ UI chrome ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ: ਨੈਵੀਗੇਸ਼ਨ, ਫਾਰਮ, ਮੀਨੂ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਸਕ੍ਰੀਨ ਲਿਖਤ।
- ਬੈਕਐਂਡ ਉਹ ਸੁਨੇਹੇ ਜੋ ਇਹ ਬਣਾਉਂਦਾ ਹੈ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ: ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ ਈਮੇਲ, ਸਰਵਰ-ਸਾਈਡ ਵੈਲਿਡੇਸ਼ਨ ਐਰਰ, ਅਤੇ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਐਰਰ ਰਿਸਪਾਂਸ ਵਜੋਂ ਵਾਪਸ ਆਉਂਦੀ ਹੈ।
- ਸ਼ੇਅਰਡ ਡੋਮੇਨ (ਜਿਵੇਂ ਆਰਡਰ ਸਥਿਤੀ ਲੇਬਲ) ਇੱਕ ਸਰੋਤ-ਸੱਚ ਤੋਂ ਆਉਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਜੋ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਦਰਮਿਆਨ ਫਰਕ ਨਾ ਆਵੇ।
ਗਲਤੀ ਜਿਸ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ: ਜਦੋਂ ਬੈਕਐਂਡ ਪੂਰੇ ਲਿਖੇ ਹੋਏ ਅੰਗਰੇਜ਼ੀ ਵਾਕ ਵਾਪਸ ਭੇਜੇ, ਤਾਂ ਫਰੰਟਐਂਡ ਉਨ੍ਹਾਂ ਨੂੰ ਸਾਫ਼-ਸੁਥਰੇ ਤਰੀਕੇ ਨਾਲ ਲੋਕਲਾਈਜ਼ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇੱਕ ਬਿਹਤਰ ਪੈਟਰਨ ਹੈ: ਬੈਕਐਂਡ ਇੱਕ ਐਰਰ ਕੋਡ ਵਾਪਸ ਭੇਜੇ (ਅਤੇ ਸ਼ਾਇਦ ਸੁਰੱਖਿਅਤ ਪੈਰਾਮੀਟਰ), ਅਤੇ ਕਲਾਇੰਟ ਉਹ ਕੋਡ ਇੱਕ ਲੋਕਲਾਈਜ਼ਡ ਸੁਨੇਹੇ ਨਾਲ ਮੇਪ ਕਰੇ।
ਕਾਪੀ ਦੀ ਮਾਲਕੀ ਪ੍ਰੋਡਕਟ ਫੈਸਲਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਵਿਵਰਣ। ਸ਼ੁਰੂ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੌਣ ਸ਼ਬਦ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਟੋਨ ਨੂੰ ਕੌਣ ਮਨਜ਼ੂਰ ਕਰੇਗਾ।
ਜੇ ਪ੍ਰੋਡਕਟ ਦਾ ਮਾਲਕ ਕਾਪੀ ਹੈ, ਤਾਂ ਅਨੁਵਾਦ ਨੂੰ ਸਮੱਗਰੀ ਵਾਂਗ ਸਮਝੋ: ਇਸ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ, ਰਿਵਿਊ ਕਰੋ ਅਤੇ ਪ੍ਰੋਡਕਟ ਨੂੰ ਬਦਲਾਵ ਦੀ ਮੰਗ ਕਰਨ ਦਾ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਦਿਓ। ਜੇ ਇੰਜੀਨੀਅਰਿੰਗ ਦਾ ਮਾਲਕ ਕਾਪੀ ਹੈ, ਤਾਂ ਨਿਯਮ ਬਣਾਓ ਕਿ ਕੋਈ ਵੀ ਨਵਾਂ UI ਸਤਰ ਇੱਕ ਕੀ ਅਤੇ ਡਿਫ਼ੌਲਟ ਅਨੁਵਾਦ ਨਾਲ ਆਵੇ ਬਿਨਾਂ ਇਸਦੇ ਸ਼ਿਪ ਹੋਣ ਦੀ ਆਗਿਆ ਨਾ ਹੋਵੇ।
ਉਦਾਹਰਣ: ਜੇ ਤੁਹਾਡੇ ਸਾਈਨਅਪ ਫਲੋ ਵਿੱਚ ਤਿਨ੍ਹਾਂ ਸੱਕਰੀਨਾਂ ਤੇ "Create account" ਆ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਕੀ ਵਿੱਚ ਬਦਲੋ ਅਤੇ ਹਰ ਜਗ੍ਹਾ ਵਰਤੋਂ। ਇਸ ਨਾਲ ਮਤਲਬ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ, ਅਨੁਵਾਦਿਕ ਤੇਜ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਅ ਇੱਕ ਬਹੁ-ਸਕ੍ਰੀਨ ਸਫ਼ਾਈ ਵਿੱਚ ਤਬਦੀਲ ਹੋਣ ਤੋ ਬਚਾਂਦਾ ਹੈ।
ਸਟਰਿੰਗ ਕੁੰਜੀਆਂ ਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਵੇ ਤਾ ਕਿ ਉਹ ਸਥਿਰ ਰਹਿਣ
ਕੁੰਜੀਆਂ ਤੁਹਾਡੇ UI ਅਤੇ ਤੁਹਾਡੇ ਅਨੁਵਾਦਾਂ ਦਰਮਿਆਨ ਕਰਾਰ (contract) ਹੁੰਦੀ ਹਨ। ਜੇ ਇਹ ਕਰਾਰ ਬਦਲਦਾ ਰਹੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਗੁਮ ਹੋਈਆਂ ਲਿਖਤਾਂ, ਜਲਦੀ ਸੁਧਾਰ ਅਤੇ ਵੈੱਬ-ਮੋਬਾਈਲ ਵਿੱਚ ਅਸਮਰਥਤਾ ਮਿਲੇਗੀ। ਚੈਟ-ਤਿਆਰ ਐਪਾਂ ਲਈ ਇੱਕ ਵਧੀਆ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ ਇਕ ਨਿਯਮ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: ਕੁੰਜੀਆਂ ਅਰਥ ਵੇਖਾਉਣ, ਨਾ ਕਿ ਮੌਜੂਦਾ ਅੰਗਰੇਜ਼ੀ ਵਾਕ ਦੀ ਵਰਣਨਾ ਕਰਨ।
ਪੂਰੇ ਵਾਕ ਦੀ ਥਾਂ ਸਥਿਰ ID ਵਰਤੋ (ਜਿਵੇਂ billing.invoice.payNow) ਨਾ ਕਿ ਪੂਰੇ ਕਾਪੀ (ਜਿਵੇਂ "Pay now")। ਵਾਕ-ਅਧਾਰਤ ਕੀਸ ਉਹ ਮੁੜ-ਲੇਖਨ ਦੇ ਨਾਲ ਤੁਰੰਤ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ ਸ਼ਬਦ-ਚੋਣ, ਵਿਸ਼ੇਸ਼-ਚਿੰਨ੍ਹ ਜਾਂ ਕੇਸ ਬਦਲਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਰੂਪ ਜੋ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦਾ ਹੈ: ਸਕ੍ਰੀਨ (ਜਾਂ ਡੋਮੇਨ) + ਕੰਪੋਨੈਂਟ + ਇਰਾਦਾ। ਬੋਰਿੰਗ ਅਤੇ ਪੇਸ਼ਗੀ-ਮੁਕਾਬਿਲ ਹੋਣ ਦਿਓ।
ਉਦਾਹਰਣ:
auth.login.titleauth.login.emailLabelbilling.checkout.payButtonnav.settingserrors.network.offline
ਫੈਸਲਾ ਕਰਨ ਲਈ ਕਿ ਇੱਕ ਕੀ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਾ ਹੈ ਜਾਂ ਨਵੀਂ ਬਣਾਉਣੀ ਹੈ, ਪੁੱਛੋ: “ਕੀ ਹਰ ਥਾਂ ਮਤਲਬ ਬਿਲਕੁਲ ਇਕੋ ਹੈ?” ਜੇ ਮਤਲਬ ਸੱਚਮੁਚ ਜਨਰਿਕ ਹੈ ਤਾਂ ਇੱਕੋ ਕੀ ਵਰਤੋ, ਪਰ ਜਦੋਂ ਸੰਦਰਭ ਬਦਲਦਾ ਹੈ ਤਾਂ ਨਵੀਂ ਕੀ ਬਣਾਉ। ਉਦਾਹਰਣ ਵਜੋਂ, Profile ਸਕ੍ਰੀਨ ਵਿੱਚ "Save" ਇੱਕ ਸੰਪੂਰਨ ਕਾਰਵਾਈ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇੱਕ ਜਟਿਲ ਸੰਪਾਦਕ ਵਿੱਚ "Save" ਨੂੰ ਕੁਝ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਵੱਖਰਾ ਟੋਨ ਲੋੜ ਸਕਦਾ ਹੈ।
ਸਾਂਝੇ UI ਲਿਖਤ ਨੂੰ ਮੁਕਤੀ ਨੈਮਸਪੇਸ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਇਹ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਦੁਰੁਭਾਵ ਨਾ ਬਣੇ। ਕੁਝ ਆਮ ਬਕੈਟ ਜਿਹੜੇ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ:
common.actions.*(save, cancel, delete)common.status.*(loading, success)common.fields.*(search, password)errors.*(validation, network)nav.*(tabs, menu items)
ਜਦੋਂ ਲਿਖਤ ਬਦਲਦੀ ਹੈ ਪਰ ਮਤਲਬ ਇੱਕੋ ਹੀ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਕੀ ਨੂੰ ਰੱਖੋ ਅਤੇ ਸਿਰਫ਼ ਅਨੁਵਾਦ ਨੂੰ ਅਪਡੇਟ ਕਰੋ। ਇਹ ਸਥਿਰ IDs ਦੀ ਮੁੱਖ ਉਦੇਸ਼ ਹੈ। ਜੇ ਮਤਲਬ ਬਦਲਦਾ ਹੈ (ਇਕੋ ਜਿਹਾ ਵੀ ਹੋਵੇ), ਤਾਂ ਨਵੀਂ ਕੀ ਬਣਾਓ ਅਤੇ ਪੁਰਾਣੀ ਨੂੰ ਤੁਰੰਤ ਨਹੀਂ ਹਟਾਓ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਹ ਪੁਸ਼ਟੀ ਨਾ ਕਰੋ ਕਿ ਇਹ ਵਰਤੋਂ ਵਿੱਚ ਨਹੀਂ। ਇਸ ਨਾਲ "ਚੁੱਪ" ਗਲਤ ਮੈਚ ਰੁਕਦੇ ਹਨ ਜਿੱਥੇ ਪੁਰਾਣਾ ਅਨੁਵਾਦ ਹੁਣ ਗਲਤ ਹੈ ਪਰ ਮੌਜੂਦ ਹੈ।
ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਣ Koder.ai-ਸਟਾਈਲ ਫਲੋ ਤੋਂ: ਤੁਹਾਡੀ ਚੈਟ React ਵੈੱਬ ਐਪ ਅਤੇ Flutter ਮੋਬਾਈਲ ਐਪ ਦੋਹਾਂ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਦੋਹਾਂ common.actions.save ਵਰਤਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਹਰ ਥਾਂ ਸਥਿਰ ਅਨੁਵਾਦ ਪ੍ਰਾਪਤ ਕਰੋਗੇ। ਪਰ ਜੇ ਵੈੱਬ profile.save ਵਰਤਦਾ ਹੈ ਅਤੇ ਮੋਬਾਈਲ account.saveButton, ਤਾਂ ਸਮੇਂ ਦੇ ਨਾਲ ਤੁਹਾਡੇ ਕੋਲ ਡ੍ਰਿਫਟ ਹੋ ਜਾਵੇਗੀ, ਭਾਵੇਂ ਅੰਗਰੇਜ਼ੀ ਅਜਿਕਲ ਇਕੋ ਜਿਹੀ ਲੱਗੇ।
ਲਿਖਤ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਅਨੁਵਾਦ ਫਾਈਲਾਂ ਨੂੰ ਕਿਸ ਤਰ੍ਹਾਂ ਸੰਗਠਿਤ ਕਰਨਾ ਹੈ
ਆਪਣੀ ਸਰੋਤ ਭਾਸ਼ਾ (ਅਕਸਰ ਅੰਗਰੇਜ਼ੀ) ਨੂੰ ਇਕੱਲਾ ਸਰੋਤ-ਸੱਚ ਮੰਨੋ। ਇਸਨੂੰ ਇੱਕ ਥਾਂ ਰੱਖੋ, ਕੋਡ ਵਾਂਗ ਰਿਵਿਊ ਕਰੋ, ਅਤੇ ਨਵੇਂ ਸਤਰਾਂ ਨੂੰ ਬੇਕਾਰ ਤੌਰ 'ਤੇ ਕਾਮਪੋਨੈਂਟਸ ਵਿੱਚ ਨਾ ਆਉਣ ਦਿਓ। ਇਹ ਹਾਰਡ-ਕੋਡ ਕੀਤੀ UI ਕਾਪੀ ਤੋਂ ਬਚਾਉਣ ਦਾ ਤੇਜ਼ੀ ਰਸਤਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਮਦਦਗਾਰ ਹੈ: ਐਪ ਸਿਰਫ਼ i18n ਸਿਸਟਮ ਤੋਂ ਲਿਖਤ ਦਿਖਾ ਸਕਦੀ ਹੈ। ਜੇ ਕਿਸੇ ਨੂੰ ਨਵੀਂ ਲਿਖਤ ਚਾਹੀਦੀ ਹੈ, ਉਹ ਪਹਿਲਾਂ ਕੀ ਅਤੇ ਡਿਫੌਲਟ ਸੁਨੇਹਾ ਜੋੜੇ, ਫਿਰ UI ਵਿੱਚ ਉਹ ਕੀ ਵਰਤੇ। ਇਹ ਤੁਹਾਡੇ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਫੀਚਰ ਇੱਕ ਖਰਾਬ ਚੈਟ-ਜਨਰੇਟ ਕੀਤੀ ਲਿਖਤ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਤਿਆਰ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਫੋਲਡਰ ਲੇਆਉਟ ਜੋ ਸੰਭਾਲ ਕੇ ਰਹਿੰਦਾ ਹੈ
ਜੇ ਤੁਸੀਂ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਦੋਹਾਂ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਸਾਂਝਾ ਕੈਟਲੌਗ ਚਾਹੁੰਦੇ ਹੋ ਕੁੰਜੀਆਂ ਦਾ, ਨਾਲ-ਨਾਲ ਫੀਚਰ ਟੀਮਾਂ ਲਈ ਜਗ੍ਹਾ ਹੋਵੇ ਤਾਂ ਜੋ ਉਹ ਇੱਕ-ਦੂਜੇ 'ਤੇ ਚੱਲਣ ਨਾ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਲੇਆਉਟ:
- /i18n
- /i18n/locales/en.json (ਸਰੋਤ)
- /i18n/locales/es.json, /i18n/locales/fr.json, ...
- /i18n/features/billing.json, /i18n/features/auth.json, ...
- /i18n/shared.json (ਬਟਨ, ਆਮ ਲੇਬਲ, ਐਰਰ)
ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਕੁੰਜੀਆਂ ਇੱਕੋ-ਜਿਹੀਆਂ ਰੱਖੋ, ਭਾਵੇਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵੱਖਰੀ ਹੋਵੇ (React ਵੈੱਬ, Flutter ਮੋਬਾਈਲ)। ਜੇ ਤੁਸੀਂ ਕੋਈ ਪਲੇਟਫਾਰਮ ਵਰਗਾ Koder.ai ਵਰਤ ਕੇ ਦੋਹਾਂ ਐਪ ਨਿਰਯਾਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਿਰਯਾਤ ਸੌਖਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਦੋਹਾਂ ਪ੍ਰੋਜੈਕਟ ਇੱਕੋ ਕੀ ਨਾਂ ਅਤੇ ਇੱਕੋ ਸੁਨੇਹਾ ਫਾਰਮੈਟ ਨੂੰ ਨਿਸ਼ਾਨੇ 'ਤੇ ਰੱਖਦੇ ਹਨ।
ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਰਿਵਿਊ ਜੋ ਅਨੁਵਾਦ ਦੀ ਮਿਆਦ ਰੋਕਦੇ ਹਨ
ਅਨੁਵਾਦ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਦੇ ਹਨ। ਬਦਲਾਵਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਬਦਲਾਵ ਵਾਂਗ ਸਮਝੋ: ਛੋਟੇ, ਰਿਵਿਊ ਕੀਤੇ ਅਤੇ ਟ੍ਰੈਕ ਕਰਨ ਯੋਗ। ਇੱਕ ਚੰਗਾ ਰਿਵਿਊ ਮਤਲਬ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੋਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ, ਸਿਰਫ਼ ਸਪੈਲਿੰਗ 'ਤੇ ਨਹੀਂ।
- ਸਰੋਤ ਭਾਸ਼ਾ ਵਿੱਚ ਕਿਸੇ ਵੀ تبدیلی ਲਈ PR ਰਿਵਿਊ ਲਾਜ਼ਮੀ ਕਰੋ
- ਕੁੰਜੀਆਂ ਨੂੰ ਡਿਲੀਟ ਕਰਨ ਨੂੰ ਖੋਜ ਅਤੇ ਯੋਜਨਾ ਬਿਨਾਂ ਰੋਕੋ
- ਜਦੋਂ ਲਿਖਤ ਅਸਪਸ਼ਟ ਹੋਵੇ, ਅਨੁਵਾਦਕਾਂ ਲਈ ਨੋਟ ਜੋੜੋ
- CI ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ “ਮਿਸਿੰਗ ਅਨੁਵਾਦ” ਚੈੱਕ ਵਰਤੋ
ਟੀਮਾਂ ਦਰਮਿਆਨ ਕੁੰਜੀਆਂ ਦੇ ਡ੍ਰਿਫਟ ਰੋਕਣ ਲਈ, ਫੀਚਰ ਦੇ ਅਧੀਨ ਕੁੰਜੀਆਂ ਦੀ ਮਲਕੀਅਤ ਤੈਅ ਕਰੋ (billing., auth.), ਅਤੇ ਮੌਜੂਦਾ ਸ਼ਬਦ-ਚੋਣ ਲਈ ਕੁੰਜੀਆਂ ਨੂੰ ਨਾਮ ਨਾ ਦਿਓ। ਕੀਸ ਤਾਂ ਪਛਾਣਕ ਹਨ, ਲਿਖਤ ਨਹੀਂ।
ਬਿਨਾਂ ਹੈਕਸ ਦੇ ਬਹੁਵਚਨ ਅਤੇ ਵਿਆਕਰਨ
Build a multilingual MVP faster
Describe your product in chat and keep all user-facing text ready for translation.
ਭਾਸ਼ਾਵਾਂ ਅਨੁਸਾਰ ਬਹੁਵਚਨ ਨਿਯਮ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਅੰਗਰੇਜ਼ੀ ਦਾ ਸਧਾਰਨ ਪੈਟਰਨ (1 ਵਿਰੁੱਧ ਬਾਕੀ) ਜਲਦੀ ਫੇਲ੍ਹ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਭਾਸ਼ਾਵਾਂ 0, 1, 2-4 ਵਰਗੇ ਵਿਭਿੰਨ ਫਾਰਮ ਰੱਖਦੀਆਂ ਹਨ। ਹੋਰਾਂ ਵਿੱਚ ਪੂਰਾ ਵਾਕ ਹੀ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪਲੁਰਲ ਲੋਜਿਕ UI ਵਿੱਚ if-else ਨਾਲ ਬੈਕ ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਕਾਪੀ ਦੀ ਨਕਲ ਅਤੇ ਐਜ ਕੇਸ ਦੀਆਂ ਗਲਤੀਆਂ ਬਣਾਉਂਦੇ ਹੋ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਹਰ ਵਿਚਾਰ ਲਈ ਇੱਕ ਲਚਕੀਲਾ ਸੁਨੇਹਾ ਰੱਖੋ ਅਤੇ i18n ਲੇਅਰ ਨੂੰ ਸਹੀ ਰੂਪ ਚੁਣਨ ਦਿਓ। ICU-ਸਟਾਈਲ ਸੁਨੇਹੇ ਇਸ ਲਈ ਬਣਾਏ ਗਏ ਹਨ। ਉਹ ਵਿਆਕਰਨ ਦੇ ਫੈਸਲੇ ਅਨੁਵਾਦ ਵਿੱਚ ਰੱਖਦੇ ਹਨ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਕੰਪੋਨੈਂਟਸ ਵਿੱਚ।
ਇੱਥੇ ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਣ ਹੈ ਜੋ ਲੋਕ ਲੋਕ ਭੁੱਲਦੇ ਹਨ:
itemsCount = "{count, plural, =0 {No items} one {# item} other {# items}}"
ਇਹ ਇਕੱਲੀ ਕੀ 0, 1 ਅਤੇ ਹੋਰ ਸਾਰੇ ਕਵਰ ਕਰ ਲੈਂਦੀ ਹੈ। ਅਨੁਵਾਦਕ ਇਸਨੂੰ ਆਪਣੀ ਭਾਸ਼ਾ ਲਈ ਠੀਕ ਬਹੁਵਚਨ ਰੂਪ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਛੇੜੇ।
ਜਦੋਂ ਤੁਹਾਨੂੰ ਲਿੰਗ ਜਾਂ ਭੂਮਿਕਾ-ਅਧਾਰਤ ਲਿਖਤ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ welcome_male ਅਤੇ welcome_female ਵਰਗੀਆਂ ਅਲੱਗ-ਅਲੱਗ ਕੁੰਜੀਆਂ ਬਣਾਉਣ ਤੋਂ ਬਚੋ (ਜਦ ਤੱਕ ਪ੍ਰੋਡਕਟ ਵਾਸਤਵ ਵਿੱਚ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ)। select ਵਰਤੋ ਤਾਂ ਜੋ ਵਾਕ ਇੱਕ ਇਕਾਈ ਵਿੱਚ ਹੀ ਰਹੇ:
welcomeUser = "{gender, select, female {Welcome, Ms. {name}} male {Welcome, Mr. {name}} other {Welcome, {name}}}"
ਵਿਆਕਰਨਿਕ ਕੇਸਾਂ ਨਾਲ ਖੇਡਣ ਤੋਂ ਬਚਣ ਲਈ, ਵਾਕਾਂ ਨੂੰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਪੂਰਾ ਰੱਖੋ। ਟੁਕੜੇ ਜੋੜ ਕੇ ਨਾ ਬਣਾਓ ਜਿਵੇਂ "{count} " + t('items') ਕਿਉਂਕਿ ਕਈ ਭਾਸ਼ਾਵਾਂ ਸ਼ਬਦਾਂ ਦਾ ਆਰਡਰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਸੁਨੇਹਾ ਜੋ ਨੰਬਰ, ਨਾਊਨ ਅਤੇ ਆਸ-ਪਾਸ ਦੇ ਸ਼ਬਦਾਂ ਸਮੇਤ ਹੋਵੇ, ਵਧੀਆ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਜੋ ਚੈਟ-ਤਿਆਰ ਐਪਾਂ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ Koder.ai ਪ੍ਰਾਜੈਕਟ ਵੀ ਸ਼ਾਮਲ ਹਨ) ਵਿੱਚ ਅਚਕਤ ਕੰਮ ਕਰਦਾ ਹੈ: ਜੇ ਕਿਸੇ ਵਾਕ ਵਿੱਚ ਨੰਬਰ, ਵਿਅਕਤੀ ਜਾਂ ਸਥਿਤੀ ਹੈ, ਤਾਂ ਦਿਨ ਇੱਕੋ ਦਿਨ ਤੋਂ ICU ਰੱਖੋ। ਇਹ ਸ਼ੁਰੂ ਵਿੱਚ ਥੋੜ੍ਹਾ ਵਧੇਰ ਖਰਚ ਹੁੰਦਾ ਹੈ ਪਰ ਬਾਅਦ ਵਿੱਚ ਅਨੁਵਾਦ ਦੀ ਬਹੁਤ ਮਿਆਦ ਬਚਾਂਦਾ ਹੈ।
ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਅਨੁਵਾਦਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ
ਜੇ ਤੁਹਾਡੀ React ਵੈੱਬ ਐਪ ਅਤੇ Flutter ਮੋਬਾਈਲ ਐਪ ਆਪਣੀਆਂ ਆਪਣੀਆਂ ਅਨੁਵਾਦ ਫਾਈਲਾਂ ਰੱਖਦੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਡ੍ਰਿਫਟ ਹੋ ਜਾਏਂਗੀਆਂ। ਇੱਕੋ ਬਟਨ ਵੱਖਰਾ ਸ਼ਬਦ ਲੈ ਲੈਂਦਾ ਹੈ, ਇੱਕ ਕੀ ਵੈੱਬ ਤੇ ਇੱਕ ਚੀਜ਼ ਲਈ ਮਤਲਬ ਦੂਜੇ ਪਲੇਟਫਾਰਮ ਤੇ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਪੋਰਟ ਟਿਕਟਾਂ ਆਰੰਭ ਕਰਦੀਆਂ ਹਨ “ਐਪ X ਕਹਿੰਦੀ ਹੈ ਪਰ ਵੈਬਸਾਈਟ Y ਕਹਿੰਦੀ ਹੈ”।
ਸਬ ਤੋਂ ਸਾਦਾ ਠੀਕ ਕਰਨ ਦਾ ਤਰੀਕਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਵੀ ਹੈ: ਇਕੋ ਸਰੋਤ-ਸੱਚ ਫਾਰਮੈਟ ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਕੋਡ ਵਾਂਗ ਵਰਤੋ। ਇੱਕ ਛੋਟੀ ਟੀਮ ਲਈ ਅਕਸਰ ਇਹ ਇਕ ਸਾਂਝਾ ਸੈਟ ਆਫ਼ ਲੋਕੇਲ ਫਾਈਲਾਂ (ਜਿਵੇਂ ICU-ਸਟਾਈਲ JSON) ਹੁੰਦਾ ਹੈ ਜੋ ਦੋਹਾਂ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਦੁਆਰਾ ਖਾਧੇ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਚੈਟ ਅਤੇ ਜਨਰੇਟਰਾਂ ਰਾਹੀਂ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਇਹ ਹੋਰ ਵੀ ਜਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਅਕਸਰ ਨਵੀਂ ਲਿਖਤ ਦੋ ਥਾਵਾਂ 'ਚ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇਕ ਸਾਂਝਾ ਸਰੋਤ-ਸੱਚ
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸੈਟਅਪ ਇੱਕ ਛੋਟੀ “i18n ਪੈਕੇਜ” ਜਾਂ ਫੋਲਡਰ ਹੈ ਜਿਸ ਵਿੱਚ:
- ਹਰ ਭਾਸ਼ਾ ਲਈ ਲੋਕੇਲ ਫਾਈਲਾਂ (ਹਰੇਕ ਜਗ੍ਹਾ ਇੱਕੋ ਕੁੰਜੀਆਂ)
- ਸੁਨੇਹਾ ਫਾਰਮੈਟ ਨਿਯਮ (ਪਲੁਰਲ ਅਤੇ ਪਲੇਸਹੋਲਡਰ ਲਈ ICU)
- ਇਕ ਛੋਟੀ README ਜੋ ਨਵੀਂ ਕੁੰਜੀ ਜੋੜਨ ਦਾ ਤਰੀਕਾ ਸਮਝਾਏ
React ਅਤੇ Flutter ਫਿਰ ਖਪਤਕਾਰ ਬਣ ਜਾਣ। ਉਹਾਂ ਨੂੰ ਨਵੀਆਂ ਕੁੰਜੀਆਂ ਖੋਜਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। Koder.ai-ਸਟਾਈਲ ਵਰਕਫਲੋ (React ਵੈੱਬ, Flutter ਮੋਬਾਈਲ) ਵਿੱਚ, ਤੁਸੀਂ ਦੋਨੋ ਕਲਾਇੰਟ ਨੂੰ ਇਕੋ ਕੁੰਜੀ ਸੈਟ ਤੋਂ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਬਦਲਾਅਾਂ ਨੂੰ ਹੋਰ ਕਿਸੇ ਕੋਡ ਬਦਲਾਅ ਵਾਂਗ ਰਿਵਿਊ ਰੱਖ ਸਕਦੇ ਹੋ।
ਬੈਕਐਂਡ ਮਿਲਾਣ ਇਸੀ ਕਹਾਣੀ ਦਾ ਹਿੱਸਾ ਹੈ। ਐਰਰ, ਸੂਚਨਾਵਾਂ ਅਤੇ ਈਮੇਲ ਗੋ ਭਾਸ਼ਾ ਵਿੱਚ ਅੰਗਰੇਜ਼ੀ ਲਿਖੇ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। ਇਸਦੀ ਥਾਂ, ਸਥਿਰ ਐਰਰ ਕੋਡ (ਜਿਵੇਂ auth.invalid_password) ਅਤੇ ਕੋਈ ਸੁਰੱਖਿਅਤ ਪੈਰਾਮੀਟਰ ਵਾਪਸ ਕਰੋ। ਫਿਰ ਕਲਾਇੰਟ ਕੋਡਾਂ ਨੂੰ ਅਨੁਵਾਦਿਤ ਸੁਨੇਹਿਆਂ ਨਾਲ ਮੇਪ ਕਰੇ। ਸਰਵਰ ਸੈਂਟ ਈਮੇਲ ਲਈ, ਸਰਵਰ ਵੀ ਉਸੇ ਕੁੰਜੀਆਂ ਅਤੇ ਲੋਕੇਲ ਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਟੇਮਪਲੇਟ ਰੇਂਡਰ ਕਰ ਸਕਦਾ ਹੈ।
ਨਿਯਮ ਜੋ ਤੁਹਾਨੂੰ ਸਿੰਕ ਵਿੱਚ ਰੱਖਦੇ ਹਨ
ਇੱਕ ਛੋਟੀ ਨਿਯਮ-ਪੁਸਤਕ ਬਣਾਓ ਅਤੇ ਕੋਡ-ਰਿਵਿਊ ਵਿੱਚ ਇਸ ਦੀ ਪਾਲਣਾ ਕਰੋ:
- ਨਵਾਂ UI ਲਿਖਤ ਪਹਿਲਾਂ ਸਾਂਝੇ ਲੋਕੇਲ ਫਾਈਲਾਂ ਵਿੱਚ ਨਵੀਂ ਕੁੰਜੀ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ
- ਕੁੰਜੀਆਂ ਨੂੰ ਸਪਸ਼ਟ ਨੈਮਸਪੇਸ ਅਤੇ ਇਰਾਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਸਕ੍ਰੀਨ ਸਥਿਤੀ ਨਹੀਂ)
- ਹਰ ਕੁੰਜੀ ਲਈ ਪਲੇਸਹੋਲਡਰ ਇਕ ਵਾਰੀ ਪਰिभਾਸ਼ਿਤ ਹੋਣ ਅਤੇ ਸਭ ਥਾਵਾਂ ਵਿੱਖੇ ਇਕੋ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣੇ ਜਾਣ
- ਜੇ ਦੋ ਵਾਕਾਂ ਦਾ ਅਰਥ ਵੱਖਰਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਕਦੇ ਇਕੋ ਕੀ ਨਹੀਂ ਸਾਂਝੀ ਕਰਨੀ ਚਾਹੀਦੀ
- ਜੇ ਦੋ ਕੁੰਜੀਆਂ ਇੱਕੋ ਮਤਲਬ ਰੱਖਦੀਆਂ ਹਨ, ਇੱਕ ਨੂੰ ਹਟਾਓ ਅਤੇ ਇੱਕ ਹੀ ਚੁਣੋ
ਡੁਪਲੀਕੇਟ ਕੁੰਜੀਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਜੋ ਵੱਖਰੇ ਮਤਲਬ ਰੱਖਦੀਆਂ ਹਨ, ਅਨੁਵਾਦਕ ਅਤੇ ਭਵਿੱਖ ਦੇ ਲਈ ਇੱਕ “description” ਫੀਲਡ (ਜਾਂ comment ਫਾਈਲ) ਜੋੜੋ। ਉਦਾਹਰਣ: billing.trial_days_left ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਇਹ ਬੈਨਰ ਵਜੋਂ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਈਮੇਲ ਵਿੱਚ — ਇਹ ਇੱਕ ਵਾਕ ਅਕਸਰ "ਕਲੋਜ਼ ਏਨਫ" ਦਿਉਂਦਾ ਹੈ ਜੋ ਗਲਤ-ਨਜ਼ਦੀਕੀ reuse ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਇਹ ਇਕੋ-ਸਾਰਤਾ ਚੈਟ-ਤਿਆਰ ਐਪਾਂ ਲਈ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ ਦੀ ਹੱਡੀ ਹੈ: ਇਕ ਸਾਂਝੀ ਸ਼ਬਦਕੋਸ਼, ਬਹੁ-ਸਰਫ਼ੇ, ਅਤੇ ਜਿਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਅਗਲਾ ਭਾਸ਼ਾ ਸ਼ਿਪ ਕਰੋਗੇ ਉਸ ਵਿੱਚ ਕੋਈ ਹੈਰਾਨੀ ਨਹੀਂ।
ਕਦਮ-ਦਰ-ਕਦਮ ਸੈਟਅਪ ਜੋ ਤੁਸੀਂ ਇੱਕ ਅਸਲੀ ਪ੍ਰਾਜੈਕਟ 'ਤੇ ਫੋਲੋ ਕਰ ਸਕਦੇ ਹੋ
Release language updates faster
Deploy and host your app so each language update is easy to test and ship.
ਚੈਟ-ਤਿਆਰ ਐਪਾਂ ਲਈ ਇੱਕ ਚੰਗਾ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ ਸਾਦਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਇਕ ਸੈਟ ਸੁਨੇਹਾ ਕੁੰਜੀਆਂ, ਇੱਕ ਸਰੋਤ-ਸੱਚ ਕਾਪੀ ਲਈ, ਅਤੇ ਇੱਕੋ ਨਿਯਮ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ (ਉਦਾਹਰਨ ਵਜੋਂ Koder.ai ਨਾਲ), ਇਹ ਢਾਂਚਾ ਰਫਤਾਰ ਨੂੰ ਬਿਨਾਂ ਅਨੁਵਾਦ ਦੀ ਮਿਆਦ ਬਣਾਉਣ ਦੇ ਕਾਬਿਲ ਰੱਖਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸੈਟਅਪ (ਵੈੱਬ + ਮੋਬਾਈਲ)
ਆਪਣੇ ਲੋਕੇਲ ਪਹਿਲਾਂ ਚੁਣੋ ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਜਦੋਂ ਅਨੁਵਾਦ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇ। ਇੱਕ ਆਮ ਚੋਣ: ਯੂਜ਼ਰ ਦੀ ਪਸੰਦੀਦਾ ਭਾਸ਼ਾ ਮੁਹੱਈਆ ਹੋਵੇ ਤਾਂ ਉਹ ਦਿਖਾਓ, ਨਹੀਂ ਤਾਂ ਅੰਗਰੇਜ਼ੀ 'ਤੇ fallback ਕਰੋ, ਅਤੇ ਗੁੰਮ ਕੁੰਜੀਆਂ ਨੂੰ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਗਲੀ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰ ਸਕੋ।
ਫਿਰ ਇਹ ਨਿਯਮ ਲਗਾਓ:
- ਲੋਕੇਲ ਅਤੇ ਫੈਲਬੈਕ ਨਿਰਧਾਰਤ ਕਰੋ: ਸਮਰਥਿਤ ਭਾਸ਼ਾਵਾਂ, ਡਿਫੌਲਟ ਲੋਕੇਲ ਅਤੇ ਇੱਕ ਫੈਲਬੈਕ ਅਰਡਰ ਨਿਰਧਾਰਤ ਕਰੋ। ਇਹ ਵੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਲੋਕੇਲ ਕਿਵੇਂ ਪਤਾ ਲਗਾਓਗੇ (ਬ੍ਰਾਉਜ਼ਰ/ਐਪ ਸੈਟਿੰਗ, ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ)।
- ਬਰਾਵਜ ਅਤੇ ਕੀ ਕੰਵੈਂਸ਼ਨ ਬਣਾਓ: ਸਥਿਰ, ਅਰਥ-ਅਧਾਰਤ ਕੁੰਜੀਆਂ ਵਰਤੋ (ਪੂਰੇ ਵਾਕ ਨਹੀਂ)। ਉਦਾਹਰਣ:
billing.plan_name.proਜਾਂauth.error.invalid_password। ਹਰ ਜਗ੍ਹਾ ਇੱਕੋ ਕੁੰਜੀ ਰੱਖੋ। - React ਅਤੇ Flutter ਵਿੱਚ ਵੀਰੱਧ ਜੁੜੋ: React ਵਿੱਚ, ਆਪਣੀ ਐਪ ਨੂੰ i18n ਪ੍ਰੋਵਾਈਡਰ ਨਾਲ ਰੈਪ ਕਰੋ ਅਤੇ ਕੰਪੋਨੈਂਟਸ ਵਿੱਚ
t("key")ਵਰਤੋ। Flutter ਵਿੱਚ, ਇਕ લોકਲਾਈਜੇਸ਼ਨ ਰੈਪਰ ਵਰਤੋ ਅਤੇ ਵਿਡਜੈੱਟਸ ਵਿੱਚ ਇਕੋ ਕੁੰਜੀ-ਅਧਾਰਤ ਲੁੱਕਅਪ ਕਰੋ। ਮਕਸਦ ਇੱਕੋ ਕੁੰਜੀਆਂ ਹਨ, ਨਾ ਕਿ ਇਕੋ ਲਾਇਬ੍ਰੇਰੀ। - ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਵਰੀਆਬਲਸ ਅਤੇ ਬਹੁਵਚਨ ਦੇ ਨਿਯਮ ਸਹਿਯੋਗ ਕਰੋ: ਬਹੁਵਚਨ ਅਤੇ ਪਲੇਸਹੋਲਡਰ ਲਈ ICU-ਸਟਾਈਲ ਸੁਨੇਹੇ ਵਰਤੋ, ਜਿਵੇਂ “{count, plural, one {# file} other {# files}}” ਅਤੇ “Hello, {name}”。 ਇਸ ਨਾਲ
if (count === 1)ਵਰਗੇ ਹੈਕਸ ਤੇ ਆਧਾਰਿਤ ਹੱਲਾਂ ਤੋਂ ਬਚਾਓ ਹੁੰਦਾ ਹੈ। - ਹਲਕਾ ਫਰਮਾ ਕਾਪੀ ਰਿਵਿਊ ਸਟੈਪ ਜੋੜੋ: ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਨਵੀਆਂ ਜਾਂ ਬਦਲੀ ਹੋਈਆਂ ਸਤਰਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ: ਕੀ ਨਾਮਕਰਨ ਠੀਕ ਹੈ, ਹਾਰਡ-ਕੋਡ ਕੀ ਵਰਤੀ ਨਹੀਂ ਗਈ, ਪਲੇਸਹੋਲਡਰ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਦੋਹਾਂ ਨੇ ਬਦਲਾਅ ਲਿਆ ਹੈ।
ਆਖ਼ਿਰ ਵਿੱਚ, ਇੱਕ ਭਾਸ਼ਾ ਦੀ ਟੈਸਟ ਕਰੋ ਜਿਸ ਵਿੱਚ ਲਫ਼ਜ਼ ਲੰਬੇ ਹੋ ਸਕਦੇ ਹਨ (ਜਰਮਨ ਇੱਕ ਕਲਾਸਿਕ ਉਦਾਹਰਣ) ਅਤੇ ਇੱਕ ਜਿਸ ਵਿੱਚ ਵਿਭਿੰਨ ਚਿੰਨ੍ਹ-ਚਿੰਨ੍ਹ ਹੁੰਦਾ ਹੈ। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਉਹ ਬਟਨ, ਸਿਰਲੇਖ ਅਤੇ ਲੇਆਉਟ ਸਮੱਸਿਆਵਾਂ ਬਿਆਨ ਕਰ ਦਿਖਾਂਦਾ ਹੈ ਜੋ ਅੰਗਰੇਜ਼ੀ ਮੰਨ ਕੇ ਡਿਜ਼ਾਈਨ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਅਨੁਵਾਦਾਂ ਨੂੰ ਸਾਂਝੇ ਫੋਲਡਰ (ਜਾਂ ਜਨਰੇਟ ਕੀਤੇ ਪੈਕੇਜ) ਵਿੱਚ ਰੱਖਦੇ ਹੋ ਅਤੇ ਕਾਪੀ ਬਦਲਾਵਾਂ ਨੂੰ ਕੋਡ ਬਦਲਾਵ ਵਾਂਗ ਸਮਝਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਇੱਕੋ ਜਿਹੇ ਰਹਿਣਗੇ ਭਾਵੇਂ ਫੀਚਰ ਤੇਜ਼ ਚੈਟ 'ਚ ਬਣ ਰਹੇ ਹੋਣ।
ਗਤੀਸ਼ੀਲ ਸਮੱਗਰੀ: ਤਾਰੀਖਾਂ, ਨੰਬਰ ਅਤੇ ਯੂਜ਼ਰ ਲਿਖਤ
ਅਨੁਵਾਦਿਤ UI ਸਤਰਾਂ ਆਰੰਭ ਹੈ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਐਪ ਵੀ ਬਦਲਦੇ ਮੁੱਲ ਦਿਖਾਉਂਦੇ ਹਨ ਜਿਵੇਂ ਤਾਰੀਖ, ਕੀਮਤ, ਗਿਣਤੀ, ਅਤੇ ਨਾਮ। ਜੇ ਤੁਸੀਂ ਉਹ ਮੁੱਲ ਸਧਾਰਨ ਟੈਕਸਟ ਵਜੋਂ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਫਾਰਮੇਟ, ਗਲਤ ਟਾਈਮਜ਼ੋਨ ਅਤੇ ਕਈ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ "ਅਜੀਬ" ਵਾਕ ਬਣਾਉਂਦੇ ਹੋ।
ਸ਼ੁਰੂਆਤ ਇਹੋ ਕਿ ਨੰਬਰ, ਕਰੰਸੀ ਅਤੇ ਤਾਰੀਖਾਂ ਨੂੰ ਭਾਸ਼ਾ-ਅਨੁਕੂਲ ਨਿਯਮਾਂ ਨਾਲ ਫਾਰਮੈਟ ਕਰੋ, ਨਾ ਕਿ ਕਸਟਮ ਕੋਡ ਨਾਲ। ਫਰਾਂਸ ਦੇ ਯੂਜ਼ਰ ਨੂੰ “1 234,50 €” ਦੀ ਉਮੀਦ ਹੋਵੇਗੀ, ਜਦਕਿ US ਯੂਜ਼ਰ ਨੂੰ “$1,234.50”。 ਇਸਦਾ ਹੀ ਅਰਥ ਤਾਰੀਖਾਂ ਲਈ ਵੀ ਹੈ: “03/04/2026” ਅਸਪਸ਼ਟ ਹੈ, ਪਰ ਲੋਕੇਲ ਫਾਰਮੇਟਿੰਗ ਨਾਲ ਇਹ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ।
ਟਾਈਮਜ਼ੋਨ ਅਗਲਾ ਫੱਬ ਹੈ। ਸਰਵਰ ਟਾਈਮਸਟੈਂਪਾਂ ਨੂੰ ਇੱਕ ਨੈਟਰਲ ਰੂਪ (ਅਕਸਰ UTC) ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਯੂਜ਼ਰ ਆਪਣੀ ਜ਼ੋਨ ਅਨੁਸਾਰ ਵੇਖਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਣ: ਇੱਕ ਆਰਡਰ ਜੋ 23:30 UTC 'ਤੇ ਬਣਿਆ, ਟੋਕਯੋ ਵਾਲੇ ਲਈ “ਕੱਲ੍ਹ” ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਕ੍ਰੀਨ-ਦਰ-ਸਕ੍ਰੀਨ ਨਿਯਮ ਬਣਾਓ: ਨਿੱਜੀ ਸਮਾਗਮ ਲਈ ਯੂਜ਼ਰ-ਲੋਕਲ ਟਾਈਮ ਦਿਖਾਓ, ਅਤੇ ਕਾਰੋਬਾਰੀ ਸਮਾਂ-ਸੂਚੀ ਲਈ ਇੱਕ ਫਿਕਸ ਬਿਜ਼ਨਸ ਟਾਈਮਜ਼ੋਨ ਦਿਖਾਓ (ਸਾਫ਼-ਸੁਚਿਤ ਲੇਬਲ ਦੇ ਨਾਲ)।
ਅਨੁਵਾਦਿਤ ਟੁਕੜੇ ਇਕੱਠੇ ਜੋੜ ਕੇ ਵਾਕ ਬਣਾਉਣ ਤੋਂ ਬਚੋ। ਇਹ ਵਿਆਕਰਨ ਨੂੰ ਤੋੜ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਸ਼ਬਦ-ਆਰਡਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਣ ਦੇ ਤੌਰ 'ਤੇ:
“{count} ” + t("items") + " " + t("in_cart")
ਦੀ ਥਾਂ ਇੱਕੋ ਸੁਨੇਹਾ ਵਰਤੋ ਜਿਸ ਵਿੱਚ ਪਲੇਸਹੋਲਡਰ ਹਨ, ਜਿਵੇਂ: “{count} items in your cart”。 ਅਨੁਵਾਦਕ ਫਿਰ ਸ਼ਬਦਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕਰਮਬੱਧ ਕਰ ਸਕਦੇ ਹਨ।
ਸੱਜੀ-ਤੋਂ-ਖੱਬੇ (RTL) ਭਾਸ਼ਾਵਾਂ
RTL ਸਿਰਫ਼ ਲਿਖਤ ਦੀ ਦਿਸ਼ਾ ਨਹੀਂ ਹੈ। ਲੇਆਉਟ ਫਲੋ ਉਲਟ ਹੁੰਦਾ ਹੈ, ਕੁਝ ਆਈਕਨ ਮਿਰਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਜਿਵੇਂ back arrow), ਅਤੇ ਮਿਲੀ-ਝੁਲੀ ਸਮੱਗਰੀ (Arabic ਨਾਲ ਇੰਗਲਿਸ਼ product code) ਅਚਾਨਕ ਤਰੀਕੇ ਨਾਲ ਦਿੱਖ ਸਕਦੀ ਹੈ। ਅਸਲੀ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਟੈਸਟ ਕਰੋ, ਸਿਰਫ਼ ਇੱਕ ਲੇਬਲ ਨਹੀਂ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ UI ਕੰਪੋਨੈਂਟ ਦਿਸ਼ਾ-ਬਦਲ ਦਾ ਸਹਿਯੋਗ ਕਰਦੇ ਹਨ।
ਯੂਜ਼ਰ-ਜਨਰੇਟ ਕੀਤੀ ਸਮੱਗਰੀ
ਉਹ ਸਮੱਗਰੀ ਜੋ ਯੂਜ਼ਰ ਨੇ ਲਿਖੀ ਹੈ (ਨਾਂ, ਪਤੇ, ਸਪੋਰਟ ਟਿਕਟਾਂ, ਚੈਟ ਮੈਸੇਜ) ਕਦੇ ਭੀ ਅਨੁਵਾਦ ਨਾ ਕਰੋ। ਤੁਸੀਂ ਗੇੜ-ਚੇੜ ਆਸ-ਪਾਸ ਦੇ ਉਹ ਲੇਬਲ ਅਨੁਵਾਦ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਮੈਟਾਡੇਟਾ (ਤਾਰੀਖ, ਨੰਬਰ) ਫਾਰਮੈਟ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਮੂਲ ਸਮੱਗਰੀ ਵਸੀਅਤ ਵਜੋਂ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਆਟੋ-ਅਨੁਵਾਦ ਜੋੜਦੇ ਹੋ, ਤਾਂ ਇਹ ਇੱਕ ਵਿਲੱਖਣ ਫੀਚਰ ਹੋਵੇ ਜਿਸਦਾ “original/translated” ਟੌਗਲ ਸਾਫ਼ ਹੋਵੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਉਦਾਹਰਣ: ਇੱਕ Koder.ai-ਬਣਾਇਆ ਐਪ ਇਹ ਦਿਖਾ ਸਕਦਾ ਹੈ “{name} renewed on {date} for {amount}”。 ਇਸਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਹੀ ਰੱਖੋ, {date} ਅਤੇ {amount} ਨੂੰ ਲੋਕੇਲ ਅਨੁਸਾਰ ਫਾਰਮੈਟ ਕਰੋ, ਅਤੇ ਯੂਜ਼ਰ ਦੀ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਦਿਖਾਓ। ਇਹ ਇਕ ਹੀ ਪੈਟਰਨ ਬਹੁਤ ਸਾਰੇ ਅਨੁਵਾਦੀ ਮੁੱਦਿਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਤੇਜ਼ ਨਿਯਮ ਜੋ ਆਮ ਤੌਰ ਤੇ ਬਗ ਰੋਕਦੇ ਹਨ:
- ਟਾਈਮਸਟੈਂਪਾਂ ਨੂੰ UTC ਵਿੱਚ ਸਟੋਰ ਕਰੋ, ਵਿਊਅਰ ਦੀ ਲੋਕੇਲ ਅਤੇ ਟਾਈਮਜ਼ੋਨ ਲਈ ਫਾਰਮੈਟ ਕਰੋ।
- ਪੂਰੇ ਵਾਕਾਂ ਵਿੱਚ ਪਲੇਸਹੋਲਡਰ ਵਰਤੋ, ਕਦੇ ਜੋੜੇ ਹੋਏ ਟੁਕੜੇ ਨਹੀਂ।
- ਕਰੰਸੀ ਨੂੰ ਲੋਕੇਲ ਨਿਯਮਾਂ ਅਤੇ ਸਹੀ ਕਰੰਸੀ ਕੋਡ ਨਾਲ ਫਾਰਮੈਟ ਕਰੋ।
- ਹਕੀਕਤੀ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ RTL ਲੋਕੇਲ ਟੈਸਟ ਕਰੋ।
- ਯੂਜ਼ਰ-ਜਨਰੇਟ ਕੀਤੀ ਟੈਕਸਟ ਨੂੰ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਅਨੁਵਾਦ ਨਾ ਕਰੋ।
ਆਮ ਗਲਤੀਆਂ ਜੋ ਅਨੁਵਾਦੀ ਮਿਆਦ ਬਣਾਉਂਦੀਆਂ ਹਨ
Get rewarded as you build
Earn credits by creating content about your build or referring others to Koder.ai.
ਅਨੁਵਾਦੀ ਮਿਆਦ ਆਮ ਤੌਰ 'ਤੇ "ਸਿਰਫ਼ ਇੱਕ ਤੁਰੰਤ ਸਕ੍ਰਿੰਗ" ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਹਫ਼ਤਿਆਂ ਦੀ ਸਫਾਈ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਚੈਟ-ਤਿਆਰ ਪ੍ਰਾਜੈਕਟਸ ਵਿੱਚ, ਇਹ ਹੋਰ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ UI ਲਿਖਤ ਕੰਪੋਨੈਂਟਸ, ਫਾਰਮਾਂ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਬੈਕਐਂਡ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਵੀ ਜਨਰੇਟ ਹੋ ਜਾਂਦੀ ਹੈ।
ਉਹ ਸਮੱਸਿਆਵਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਦੁਖ ਪਹੁੰਚਾਉਂਦੀਆਂ ਹਨ
ਸਭ ਤੋਂ ਮਹੰਗੀਆਂ ਸਮੱਸਿਆਵਾਂ ਉਹ ਹਨ ਜੋ ਐਪ 'ਚ ਫੈਲ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਲੱਭਣ ਲਈ ਔਖੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
- UI ਕੰਪੋਨੈਂਟਸ ਦੇ ਅੰਦਰ ਕਾਪੀ ਦਾ ਹਾਰਡ-ਕੋਡ ਕਰਨਾ, ਸਮੇਤ placeholders, ਖਾਲੀ ਸਟੇਟ ਅਤੇ ਬਟਨ ਲੇਬਲ। ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਆਡਿਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੋਂ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਛੋਟਾ-ਛੋਟਾ ਬਦਲਾਅ ਕੋਡ ਐਡੀਟ ਦੀ ਲੋੜ ਬਣ ਜਾਂਦਾ ਹੈ।
- ਬੈਕਐਂਡ ਵੈਲਿਡੇਸ਼ਨ ਅਤੇ API ਐਰਰਾਂ ਨੂੰ ਅੰਗਰੇਜ਼ੀ ਵਾਕ ਵਜੋਂ ਵਾਪਸ ਭੇਜਣਾ। UI ਮਿਲੀ-ਜੁਲੀ ਭਾਸ਼ਾਵਾਂ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਐਰਰਾਂ ਨੂੰ ਭਰੋਸੇ ਨਾਲ ਅਨੁਵਾਦ ਨਹੀਂ ਕਰ ਸਕਦੇ।
- ਅਨੁਵਾਦ ਕੁੰਜੀ ਵਜੋਂ ਪੂਰਾ ਅੰਗਰੇਜ਼ੀ ਵਾਕ ਵਰਤਣਾ। ਇਹ ਸੌਖਾ ਲੱਗਦਾ ਹੈ ਪਰ ਜਦੋਂ ਕਾਪੀ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਕੁੰਜੀਆਂ churn ਹੁੰਦੀਆਂ ਹਨ, ਪੁਰਾਣੀਆਂ ਕੁੰਜੀਆਂ ਰਹਿ ਜਾਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਅਨੁਵਾਦ Memorial ਖੋ ਦਿੰਦੇ ਹੋ।
- ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਵਿੱਚ ਕੁੰਜੀਆਂ ਦੀ ਨਕਲ ਕਰਕੇ ਫਿਰ ਵੱਖਰਾ-ਵੱਖਰਾ ਸੋਧ ਕਰਨਾ। ਸਮੇਂ ਦੇ ਨਾਲ, "ਉਹੀ" ਸਕ੍ਰੀਨ ਦਰਮਿਆਨ ਡ੍ਰਿਫਟ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਅਸੰਗਤ ਲਫ਼ਜ਼ ਵੇਖਦੇ ਹਨ।
- ਪਹਿਲੀ ਨਾਨ-ਅੰਗਰੇਜ਼ੀ ਭਾਸ਼ਾ ਜੋੜਨ ਤੱਕ ਬਹੁਵਚਨ ਨਿਯਮਾਂ ਨੂੰ ਟਾਲਨਾ। ਫਿਰ ਤੁਸੀਂ ਸੈਂਕੜੇ "1 items" ਦੀਆਂ ਬਗਾਂ ਅਤੇ ਅਣਢੈਰ ਵਿਆਕਰਨ ਲੱਭਦੇ ਹੋ ਜੋ ਆਸਾਨ if-statements ਨਾਲ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਇੱਕ ਤੇਜ਼ ਉਦਾਹਰਣ (ਅਸਲੀ ਜ਼ਿੰਦਗੀ ਕੀ ਦਿਸਦਾ ਹੈ)
ਕਲਪਨਾ ਕਰੋ ਇੱਕ React ਵੈੱਬ ਐਪ ਅਤੇ ਇੱਕ Flutter ਮੋਬਾਈਲ ਐਪ ਦੋਹਾਂ ਇੱਕ ਬਿਲਿੰਗ ਬੈਨਰ ਦਿਖਾਉਂਦੇ ਹਨ: “You have 1 free credit left”。 ਕਿਸੇ ਨੇ ਵੈੱਬ ਟੈਕਸਟ ਨੂੰ ਬਦਲ ਕੇ “You have one credit remaining” ਕਰ ਦਿੱਤਾ ਅਤੇ ਕੁੰਜੀ ਨੂੰ ਪੂਰੇ ਵਾਕ ਵਜੋਂ ਰੱਖ ਦਿੱਤਾ। ਮੋਬਾਈਲ ਅਜੇ ਵੀ ਪੁਰਾਣੀ ਕੁੰਜੀ ਵਰਤ ਰਿਹਾ ਹੈ। ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕੋ ਕੰਸੈਪਟ ਲਈ ਦੋ ਕੁੰਜੀਆਂ ਹਨ, ਅਤੇ ਅਨੁਵਾਦਕ ਦੋਹਾਂ ਨੂੰ ਵੇਖਦੇ ਹਨ।
ਇੱਕ ਬਿਹਤਰ ਪੈਟਰਨ ਸਥਿਰ ਕੁੰਜੀਆਂ (ਉਦਾਹਰਨ billing.creditsRemaining) ਅਤੇ ICU ਸੁਨੇਹੇ ਨਾਲ ਬਹੁਵਚਨ ਹੈ, ਤਾਂ ਕਿ ਵਿਆਕਰਨ ਹਰ ਭਾਸ਼ਾ ਲਈ ਸਹੀ ਰਹੇ। ਜੇ ਤੁਸੀਂ ਕੋਈ vibe-coding ਟੂਲ ਵਰਗਾ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਇੱਕ ਨਿਯਮ ਸ਼ੁਰੂ ਵਿੱਚ ਜੁੜੋ: ਕਿਸੇ ਵੀ ਯੂਜ਼ਰ-ਮੁਖੀ ਲਿਖਤ ਜੋ ਚੈਟ ਵਿੱਚ ਤਿਆਰ ਹੋਈ ਉਸ ਨੂੰ ਟ੍ਰਾਂਸਲੇਸ਼ਨ ਫਾਈਲਾਂ ਵਿੱਚ ਜਾਉਣ ਦਿਓ, ਨਾ ਕਿ ਕੰਪੋਨੈਂਟਸ ਜਾਂ ਸਰਵਰ-ਏਰਰਾਂ ਵਿੱਚ। ਇਹ ਛੋਟੀ ਆਦਤ ਤੁਹਾਡੇ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਵਧਣ ਸਮੇਂ ਬਚਾਂਦੀ ਹੈ।
ਤੇਜ਼ ਚੈੱਕਲਿਸਟ, ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਣ, ਅਤੇ ਅਗਲੇ ਕਦਮ
ਜਦੋਂ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਗਡਬਡ ਲੱਗਦਾ ਹੈ, ਅਕਸਰ ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿ ਬੁਨਿਆਦੀ ਨਿਯਮ ਕਦੇ ਲਿਖੇ ਨਹੀਂ ਗਏ। ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਅਤੇ ਇੱਕ ਠੋਸ ਉਦਾਹਰਣ ਤੁਹਾਡੀ ਟੀਮ (ਅਤੇ ਭਵਿੱਖ ਦੇ ਤੁਸੀਂ) ਨੂੰ ਅਨੁਵਾਦੀ ਮਿਆਦ ਤੋਂ ਬਚਾ ਸਕਦੇ ਹਨ।
ਹੇਠਾਂ ਹਰ ਨਵੇਂ ਸਕ੍ਰੀਨ 'ਤੇ ਤੁਸੀਂ ਚਲਾ ਸਕਦੇ ਹੋ ਇੱਕ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ:
- ਸਥਿਰ ਕੁੰਜੀਆਂ: ਇੱਕ ਮਤਲਬ ਲਈ ਇੱਕ ਕੀ, ਨਾ ਕਿ ਇੱਕ wording ਲਈ (ਉਦਾਹਰਨ:
billing.invoice.paidStatus, ਨਾbilling.greenLabel). - ਫੈਲਬੈਕ: ਇੱਕ ਸਪਸ਼ਟ ਡਿਫੌਲਟ ਭਾਸ਼ਾ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਜੇ ਕੋਈ ਕੀ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਕੀ ਹੋਵੇ (fallback ਟੈਕਸਟ ਦਿਖਾਓ, ਲੌਗ ਕਰੋ, ਜਾਂ ਰਿਲੀਜ਼ ਨੂੰ ਰੋਕੋ)।
- ਬਹੁਵਚਨ ਨਿਯਮ: ਗਿਣਤੀਆਂ ਲਈ ICU-ਸਟਾਈਲ ਸੁਨੇਹੇ ਵਰਤੋ (0, 1, many) ਸਧਾਰਨ ਸਟਰਿੰਗ ਹੈਕਸ ਦੀ ਥਾਂ।
- ਫਾਰਮੈਟਿੰਗ: ਤਾਰੀਖਾਂ, ਪੈਸੇ ਅਤੇ ਨੰਬਰਾਂ ਨੂੰ ਲੋਕੇਲ ਦੇ ਨਿਯਮਾਂ ਨਾਲ ਫਾਰਮੈਟ ਕਰੋ (ਅਤੇ ਭਾਸ਼ਾ ਤੋਂ ਕਰੰਸੀ ਨੂੰ ਵੱਖ ਕਰੋ)।
- RTL ਚੈੱਕ: ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸੱਜੀ-ਤੋਂ-ਖੱਬੇ ਭਾਸ਼ਾ ਨੂੰ ਜਲਦੀ ਟੈਸਟ ਕਰੋ ਤਾਂ ਕਿ ਲੇਆਉਟ ਸਮੱਸਿਆਵਾਂ 200 ਸਕ੍ਰੀਨਾਂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਨਜ਼ਰ ਆ ਜਾਣ।
ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ: ਤੁਸੀਂ English, Spanish, ਅਤੇ Japanese ਵਿੱਚ ਇੱਕ ਬਿਲਿੰਗ ਸਕ੍ਰੀਨ ਲਾਂਚ ਕਰ ਰਹੇ ਹੋ। UI ਵਿੱਚ ਹੈ: “Invoice”, “Paid”, “Due in 3 days”, “1 payment method” / “2 payment methods”, ਅਤੇ ਟੋਟਲ “$1,234.50”。 ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਚੈਟ-ਤਿਆਰ ਐਪਾਂ ਲਈ ਅੰਤਰਰਾਸ਼ਟਰੀਕਰਨ ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਬਣਾਉਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਵਾਰੀ ਕੁੰਜੀਆਂ ਨੂੰ ਪਰिभਾਸ਼ਿਤ ਕਰਦੇ ਹੋ (ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਲਈ ਸਾਂਝੀਆਂ), ਅਤੇ ਹਰ ਭਾਸ਼ਾ ਸਿਰਫ਼ ਮੁੱਲ ਭਰਦੀ ਹੈ। “Due in {days} days” ICU ਸੁਨੇਹਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮਨੀ ਫਾਰਮੈਟਿੰਗ ਲੋਕੇਲ-ਸਚੇ ਫਾਰਮੈਟਰ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਹਾਰਡ-ਕੋਡ ਕੀਤੇ ਕਾਮਾ ਤੋਂ।
ਭਾਸ਼ਾ ਸਮਰਥਨ ਨੂੰ ਫੀਚਰ-ਬਾਈ-ਫੀਚਰ ਰੋਲ-ਆਉਟ ਕਰੋ, ਨਾ ਕਿ ਇੱਕ ਵੱਡੇ ਰੀਰਾਈਟ ਵਜੋਂ:
- ਇੱਕ ਉੱਚ-ਟ੍ਰੈਫਿਕ ਫਲੋ (billing, onboarding, ਜਾਂ checkout) ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।
- ਹਾਰਡ-ਕੋਡ ਕੀਤੀ UI ਕਾਪੀ ਨੂੰ ਅਨੁਵਾਦ ਫਾਈਲਾਂ ਵਿੱਚ ਲਿਜਾਓ ਅਤੇ ਕੁੰਜੀਆਂ ਨਾਲ ਬਦਲੋ।
- ਉਸੇ ਫਲੋ ਲਈ ਬਹੁਵਚਨ ਸੁਨੇਹੇ ਅਤੇ ਫਾਰਮੈਟਿੰਗ ਜੋੜੋ।
- ਅਗਲੇ ਫੀਚਰ ਤੱਕ ਫੈਲੋ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਗੁੰਮ ਕੁੰਜੀਆਂ ਲਗਭਗ ਜ਼ੀਰੋ ਨਹੀਂ ਰਹਿ ਜਾਂਦੀਆਂ।
ਦੋ ਚੀਜ਼ਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਜੋ ਨਵੀਂ ਫੀਚਰਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਰਹਿਣ:
- ਤੁਹਾਡੇ ਕੀ ਨਾਮਕਰਨ ਨਿਯਮ (ਉਦਾਹਰਨਾਂ ਸਮੇਤ)
- ਸਤਰਾਂ ਲਈ "definition of done" (ਕੋਈ ਹਾਰਡ-ਕੋਡ ਕਾਪੀ ਨਹੀਂ, ਬਹੁਵਚਨ ਲਈ ICU, ਤਾਰੀਖ/ਨੰਬਰ ਫਾਰਮੈਟਿੰਗ, ਸਾਂਝੇ ਕੈਟਲੌਗ ਵਿੱਚ ਜੋੜਨਾ)
ਅਗਲੇ ਕਦਮ: ਜੇ ਤੁਸੀਂ Koder.ai 'ਚ ਨਿਰਮਾਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਦੀ ਵਰਤੋਂ ਕਰੋ ਕਿ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਕੁੰਜੀਆਂ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੀਆਂ ਜਾਣ। ਫਿਰ snapshots ਅਤੇ rollback ਵਰਤੋਂ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਾਪੀ ਅਤੇ ਅਨੁਵਾਦਾਂ 'ਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇਟਰੈਟ ਕਰ ਸਕੋ ਬਿਨਾਂ ਰਿਲੀਜ਼ ਟੁੱਟਣ ਦੇ ਖ਼ਤਰੇ ਦੇ।