2011/1/17 Adrián Chaves Fernández <adriyeticha...@gmail.com>: > On Monday 17 January 2011 17:35:13 mvillarino wrote: >> Eis o caso: npi. >> >> Pero pódese comprobar que use datos de varias mmtt diferentes creando >> un proxecto novo e povoando a súa mmtt con cousas con "peculiaridades" >> (por exemplo, as traducións xtest), e logo no proxecto real, vendo se >> propón suxestións dese proxecto >> O xtest é ese idioma falso que se usa pero non para comprobar que na >> interface non queden textos sen i18n. Contén os mesmos textos que no >> en_us, antecedidos e seguidos de "xx" (p. ex File -> xxFilexx). >> Como polo xeito de obtelo (agás cousas da periodicidade) está sempre >> ao 100%, calquera mensaxe sen tradución debería recuperar as mensaxes >> da mt dese proxecto > > Eu asumín que está integrado pola imaxe anexa, máis nada (así que pode que me > equivoque e só use un de cada vez, pero como non hai ningún «Escoller» asumo > que non, que os usa todos).
Non confundamos glosarios con memorias de tradución. Xa desde hai varias versións o Lokalize permitia crear varias memorias de tradución. Pero se creas un proxecto chamado «proba» as suxestións de memoria de tradución só poden proceder dunha memoria de tradución chamada «proba» por moitas memorias de tradución que teña o Lokalize configuradas. O que pregunta Marce (se entendín ben) é se por fin eliminaron esta estúpida restrición e se pode indicar no proxecto as MT que pode usar e se se pode indicar unha prioridade entre elas. Por exemplo se creas un proxecto para traducir o Inkscape seguramente queiras usar memorias de tradución creadas para o Krita, o Gimp, Scribus... pero ante todo queres que a memoria de tradución de Inkscape (con traducións anteriores de Inkscape) sexa a que teña a maior preferencia sobre todas as demais. Non sei se me explico. E si, penso que para os glosarios (terminoloxía) debería haber algo semellante. Deica _______________________________________________ Proxecto mailing list Proxecto@trasno.net http://listas.trasno.net/listinfo/proxecto