Suponha que você tenha um aplicativo traduzido que usa um mapeamento de chave para texto de localidade.
É tentador estruturar suas chaves de forma que você possa reutilizá-las em lugares que exigem o mesmo texto. O benefício óbvio é que você poupa algumas linhas e supostamente fornece uma interface de linguagem mais consistente.
No entanto, vamos examinar algumas desvantagens:
Você supostamente fornece uma interface consistente, porque para fazer isso, significa que toda vez que você quiser dizer algo em uma página, você deve revisar todo o arquivo de locale e ver se já há algo que se encaixa nele. Conforme o aplicativo cresce, isso leva cada vez mais tempo. Acrescente a isso o fato de que um dia você pode mudar aquela tradução para ajustar a comunicação de uma determinada página, e fazer com que ela afete injustamente várias outras páginas, que não têm nada a ver com essa mudança.
Se seu arquivo de localidade não for estruturado por páginas (como em, uma página e todas as chaves de texto que são usadas nele), será mais difícil olhar para o arquivo de localidade e saber o que é usado onde. Isso é extremamente importante para desenvolvedores e tradutores. Para desenvolvedores, porque precisam de uma forma rápida de saber onde inserir uma nova chave, e não começar a pensar nisso; para tradutores, porque eles precisam saber o que é usado e onde, enquanto trabalham na tradução.
Agora vamos considerar algumas dicas:
Pode ser útil adicionar uma subárvore “compartilhada”, apenas para aquelas coisas que realmente precisam ser reutilizadas. Em outras palavras, não há reutilização por padrão, mas é possível se você precisar, onde poderia realmente ajudá-lo.
Se você precisar editar seu arquivo de localidade e alterar algumas coisas que são repetidas várias vezes, então apenas reserve um tempo e trabalhe manualmente (ei, pelo menos é O (n)) ou escreva um script para fazer isso por você . O que você estimar para economizar mais tempo.