ਹਾਲ ਹੀ ਵਿੱਚ ਰਿਲੀਜ਼ ਕੀਤੇ ਗਏ Cache-Control analyzer ਦੇ ਅੰਗਰੇਜ਼ੀ ਵਰਜ਼ਨ ਵਿੱਚ ਜਾਪਾਨੀ ਟੈਕਸਟ ਦਿਖਾਈ ਦਿੱਤਾ—ਇਸਦਾ ਸਟੇਟਸ "Fresh" ਦੀ ਬਜਾਏ "新鮮" ਦਿਖਾ ਰਿਹਾ ਸੀ। ਇਹ ਗਲਤੀ ਉਸ ਸਾਂਝੀ ਲੌਜਿਕ (shared logic) ਕਾਰਨ ਹੋਈ ਜੋ ਹਾਰਡ-ਕੋਡਡ ਜਾਪਾਨੀ ਸਟ੍ਰਿੰਗਾਂ ਵਾਪਸ ਕਰ ਰਹੀ ਸੀ, ਜਦੋਂ ਕਿ ਪੇਜ ਸਿਰਫ਼ ਅੰਗਰੇਜ਼ੀ ਲੇਬਲਾਂ ਦੀ ਸਪਲਾਈ ਕਰ ਰਿਹਾ ਸੀ।
ਡਿਵੈਲਪਰ ਹਲਕੇ-ਫੁੱਲਕੇ (lightweight) ਬ੍ਰਾਊਜ਼ਰ ਟੂਲਜ਼ ਦੀ ਇੱਕ ਲੜੀ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਦਾ ਇੱਕ ਅੰਗਰੇਜ਼ੀ ਪੇਜ ਅਤੇ ਇੱਕ ਜਾਪਾਨੀ ਪੇਜ ਹੁੰਦਾ ਹੈ ਜੋ ਇੱਕੋ ਜਿਹੇ ਪਾਰਸਿੰਗ ਫੰਕਸ਼ਨਾਂ ਅਤੇ ਕੋਰ ਲੌਜਿਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਸਿਰਫ਼ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਸ਼ਬਦ ਵੱਖਰੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਜਦੋਂ Cache-Control analyzer ਰਿਲੀਜ਼ ਹੋਇਆ, ਤਾਂ ਅੰਗਰੇਜ਼ੀ ਇੰਟਰਫੇਸ ਨੇ ਸਹੀ ਲੇਬਲ ਦਿਖਾਏ, ਪਰ ਜੋ ਮੁੱਲ (values) ਦਿਖਾਏ ਗਏ ਸਨ ਉਹ ਲੌਜਿਕ ਲੇਅਰ ਤੋਂ ਆ ਰਹੇ ਸਨ, ਜਿਸ ਵਿੱਚ ਅਜੇ ਵੀ ਜਾਪਾਨੀ ਲਿਟਰਲਜ਼ (literals) ਮੌਜੂਦ ਸਨ। ਕੋਈ ਕੰਸੋਲ ਐਰਰ (console error) ਨਹੀਂ ਆਇਆ; ਪੇਜ ਆਮ ਲੱਗ ਰਿਹਾ ਸੀ, ਫਿਰ ਵੀ ਅੰਗਰੇਜ਼ੀ ਬੋਲਣ ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਦਿੱਤੀ ਗਈ ਜਾਣਕਾਰੀ ਗਲਤ ਸੀ।
ਕਿਉਂ ਸਾਂਝੀ ਲੌਜਿਕ ਅਨੁਵਾਦ ਵਿੱਚ ਧੋਖਾ ਦੇ ਸਕਦੀ ਹੈ
ਇਹ ਬੱਗ (bug) ਇੱਕ ਡਿਜ਼ਾਈਨ ਚੋਣ ਕਾਰਨ ਪੈਦਾ ਹੋਇਆ ਸੀ: ਉਹ ਕੋਰ ਫੰਕਸ਼ਨ ਜੋ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਦਿਖਾਉਣਾ ਹੈ, ਉਹ ਜਾਪਾਨੀ ਵਿੱਚ ਲਿਟਰਲ ਸਟ੍ਰਿੰਗਾਂ ਵਾਪਸ ਕਰ ਰਿਹਾ ਸੀ। ਪੇਜ ਲੇਅਰ, ਜੋ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਅੰਗਰੇਜ਼ੀ ਟੈਕਸਟ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਸੀ, ਨੂੰ ਉਹਨਾਂ ਮੁੱਲਾਂ ਨੂੰ ਬਦਲਣ ਦਾ ਮੌਕਾ ਕਦੇ ਮਿਲਿਆ ਹੀ ਨਹੀਂ। ਕਿਉਂਕਿ ਲੌਜਿਕ ਅਤੇ UI ਨੂੰ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਵੱਖ ਕੀਤਾ ਗਿਆ ਸੀ, ਇਸ ਲਈ ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਸਮੱਸਿਆ ਦਿਖਾਈ ਨਹੀਂ ਦਿੱਤੀ—ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ "ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ", ਭਾਵੇਂ ਕਿ ਉਪਭੋਗਤਾ-ਮੁਖੀ ਭਾਸ਼ਾ ਗਲਤ ਸੀ।
ਇਸਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਸਾਂਝੇ ਮੋਡਿਊਲ (shared module) ਦੇ ਅੰਦਰ ਵਰਤੀ ਗਈ ਭਾਸ਼ਾ ਹਰ ਉਸ ਫਰੰਟ-ਐਂਡ ਲਈ ਡਿਫੌਲਟ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕਿਸੇ ਵੱਖਰੀ ਭਾਸ਼ਾ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਇਹ ਡਿਫੌਲਟ ਇੱਕ ਲੁਕਿਆ ਹੋਇਆ ਬੱਗ ਬਣ ਜਾਂਦਾ ਹੈ।
ਹੱਲ: ਕੀਜ਼ (keys), ਪੈਕਸ (packs), ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਆ ਜਾਲ (safety net)
ਲੇਖਕ ਨੇ ਵੱਖ-ਵੱਖ ਕੰਮਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਲਈ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ:
- ਮੈਸੇਜ ਪੈਕਸ (Message packs) ਹੁਣ ਹਰ ਭਾਸ਼ਾ ਲਈ ਸਾਰੀਆਂ ਮਨੁੱਖੀ-ਪੜ੍ਹਨਯੋਗ ਸਟ੍ਰਿੰਗਾਂ ਰੱਖਦੇ ਹਨ।
- ਸਾਂਝੀ ਲੌਜਿਕ (Shared logic) ਸਿਰਫ਼ ਪ੍ਰਤੀਕਾਤਮਕ ਕੀਜ਼ (symbolic keys) ਵਾਪਸ ਕਰਦੀ ਹੈ, ਕਦੇ ਵੀ ਕੱਚਾ ਟੈਕਸਟ (raw text) ਨਹੀਂ।
- ਪੇਜ (Pages) ਕੀ (key) ਦੇ ਅਧਾਰ 'ਤੇ ਸਬੰਧਤ ਪੈਕ ਤੋਂ ਉਚਿਤ ਸ਼ਬਦ ਲੱਭਦੇ ਹਨ।
ਜਦੋਂ ਕਿਸੇ ਮੈਸੇਜ ਵਿੱਚ ਨੰਬਰ ਸ਼ਾਮਲ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੋਵੇ, ਤਾਂ ਨਵਾਂ ਕੋਡ ਟੈਂਪਲੇਟ ਸਟ੍ਰਿੰਗ ਦੀ ਬਜਾਏ ਇੱਕ ਛੋਟੇ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਹ ਹਰ ਭਾਸ਼ਾ ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਨੰਬਰ ਕਿੱਥੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸ਼ਬਦਾਂ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਅੰਤਰ ਨੂੰ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਸਟੈਟਿਕ-ਐਨਾਲਸਿਸ (static-analysis) ਕਦਮ ਵੀ ਜੋੜਿਆ ਗਿਆ ਸੀ: ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਸਾਂਝੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਜਾਪਾਨੀ ਅੱਖਰਾਂ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਅੱਖਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਡਿਵੈਲਪਰ ਨੂੰ ਤੁਰੰਤ ਸੂਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਹਾਰਡ-ਕੋਡਡ ਵਿਦੇਸ਼ੀ ਟੈਕਸਟ ਨੂੰ ਦੁਬਾਰਾ ਅੰਦਰ ਆਉਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇਸ ਅਨੁਭਵ ਨੇ ਲੇਖਕ ਨੂੰ ਕੀ ਸਿਖਾਇਆ
- ਅਨੁਵਾਦ ਇੱਕ ਰਿਵਿਊ ਪਾਸ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਅੰਗਰੇਜ਼ੀ ਮੈਸੇਜ ਲਿਖਦੇ ਸਮੇਂ, ਲੇਖਕ ਨੇ ਨੋਟ ਕੀਤਾ ਕਿ ਕੁਝ ਜਾਪਾਨੀ ਸਮਾਨਾਰਥੀ ਸ਼ਬਦ ਅਸਪਸ਼ਟ ਸਨ। ਅਨੁਵਾਦ ਕਰਨ ਨਾਲ ਦੋਵਾਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਵਧੇਰੇ ਸਪਸ਼ਟ ਵਾਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਮਜਬੂਰੀ ਹੋਈ।
- ਸਾਂਝੇ ਫੰਕਸ਼ਨ ਜੋ ਸਟ੍ਰਿੰਗਾਂ ਵਾਪਸ ਕਰਦੇ ਹਨ, ਉਹ ਹਰ ਕਿਸੇ ਲਈ ਇੱਕ ਭਾਸ਼ਾ ਨੂੰ ਤੈਅ ਕਰ ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਕੋਈ ਫੰਕਸ਼ਨ ਭਾਸ਼ਾ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ ਉਪਭੋਗਤਾ ਜੋ ਵੱਖਰੀ ਭਾਸ਼ਾ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਉਸ ਨੂੰ ਉਹ ਗਲਤੀ ਵਿਰਸੇ ਵਿੱਚ ਮਿਲਦੀ ਹੈ। ਇਹ ਬੱਗ ਕੋਈ UI ਗਲਤੀ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਲੌਜਿਕ ਦੀ ਖਾਮੀ ਹੈ।
ਬਹੁ-ਭਾਸ਼ਾਈ ਟੂਲਜ਼ ਦੀ ਦੇਖਭਾਲ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ ਸਿਫ਼ਾਰਸ਼ਾਂ
- ਕੋਰ ਫੰਕਸ਼ਨਾਂ ਤੋਂ ਸਟ੍ਰਿੰਗਾਂ ਦੀ ਬਜਾਏ ਕੀਜ਼ (keys) ਵਾਪਸ ਕਰੋ। UI ਲੇਅਰ ਨੂੰ ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ (localization) ਸੰਭਾਲਣ ਦਿਓ।
- ਜਾਂ ਲੋੜੀਂਦੀਆਂ ਸਟ੍ਰਿੰਗਾਂ ਨੂੰ ਪੈਰਾਮੀਟਰਾਂ ਵਜੋਂ ਫੰਕਸ਼ਨ ਵਿੱਚ ਪਾਸ ਕਰੋ। ਇਹ ਲੌਜਿਕ ਨੂੰ ਭਾਸ਼ਾ ਤੋਂ ਸੁਤੰਤਰ ਰੱਖਦਾ ਹੈ।
- ਹਾਰਡ-ਕੋਡਡ ਮੂਲ-ਭਾਸ਼ਾ ਟੈਕਸਟ ਲਈ ਸਾਂਝੇ ਮੋਡਿਊਲ ਦੀ ਜਾਂਚ ਕਰੋ। non-ASCII ਅੱਖਰਾਂ ਲਈ ਇੱਕ ਤੇਜ਼ ਖੋਜ ਲੁਕੀਆਂ ਹੋਈਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆ ਸਕਦੀ ਹੈ।
- ਸਾਂਝੇ ਕੋਡ ਵਿੱਚ ਵਿਦੇਸ਼ੀ ਅੱਖਰਾਂ ਲਈ ਬਿਲਡ-ਟਾਈਮ ਚੈੱਕ ਜੋੜੋ। ਜਲਦੀ ਪਤਾ ਲਗਾਉਣਾ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਦੀ ਉਲਝਣ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।
ਅੱਗੇ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਹੈ
ਸਿੱਖਿਆ: ਜੇਕਰ ਤੁਹਾਡਾ ਪ੍ਰੋਜੈਕਟ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾ ਵਰਜ਼ਨਾਂ ਵਿਚਕਾਰ ਕੋਡ ਸਾਂਝਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਾਂਝਾ ਹਿੱਸਾ ਕਦੇ ਵੀ ਸ਼ਬਦਾਂ ਦਾ ਫੈਸਲਾ ਨਾ ਕਰੇ। ਹਰ ਪੇਜ ਨੂੰ ਆਪਣੇ ਸ਼ਬਦ ਖੁਦ ਪ੍ਰਦਾਨ ਕਰਨ ਦਿਓ, ਅਤੇ ਤੁਸੀਂ ਅੰਗਰੇਜ਼ੀ ਪੇਜ ਦੇ ਅਚਾਨਕ ਜਾਪਾਨੀ ਬੋਲਣ ਦੀ ਸ਼ਰਮਿੰਦਗੀ ਤੋਂ ਬਚ ਜਾਓਗੇ।