El dg 16 de 09 de 2012 a les 14:35 -0400, en/na Chris Leonard va escriure: > On Sun, Sep 16, 2012 at 12:31 PM, Gil Forcada <[email protected]> wrote: > > >> I am entirely in favor of filing i18n bugs to promote common-sense > >> string conventions when possible (Why have "Zoom in" and Zoom In" and > >> 'ZOOM IN" if you can possibly agree on one string), but even then it > >> is a matter of getting devs to agree on one convention. > > > > That's another issue that I would really like to see happening, someone > > stepping in and adding some cohesion/consistency to original strings. a > > GWOP/GHOPC would be really useful here. Anyone stepping in to do > > administrate it? :) > > Can you define the acronyms GWOP/GHOPC?
Sorry for being so late replying... GWOP: GNOME Women Outreach Program GHOPC: Google Highly Open Program Contest (or some sort, sorry no Internet connection right now) And just to generally reply to you: yes consistency matters and the more consistency we get on en_US the better or easier it will get consistency on translations too :) We lack the tools or (wo)manpower to do so though, that's why I suggested that we could use GWOP and/or GHOPC to get some consistency. Cheers, > I am generally interested in cross-project consistency. > > First, there is the purpose of providing a user experience that > enhances package-to-package "transferable skills" learning (as in > "Gee, I bet I know what 'Save' does, but I have no idea what this > 'Preserve' / 'Retain' / 'Keep' item in the pull-down menu means). > Consistency of original string (and its translation) in common > pull-down menu items (in particular) is a desirable feature, not > always attainable, but worth working towards. > > It is also a lot easier to look for consistency in translations if > there is consistency in the original en_US strings. Subtle, but > essentially meaningless, variations in the original (e.g. > capitalization, punctuation on short strings, etc.) just makes those > larger-scale translation consistency analyses more complex. > > Secondly, there are the hopefully obvious advantages to localizers in > making on-line translation memory efforts more useful (e.g. Amagama, > open-trans.eu, etc.), again it helps if the en_US strings have a > sensible consistency. > > There will not always be a one-to-one match from an en_US string to a > term in a given language, context is obviously critical, but that is > why we have human translations, to include the critical element of > judgment. > > The language universe of computer program UIs is somewhat more limited > than the full complexity of human language. There are only so many > ways to describe the functions performed by a word processor or a > chess game. Voluntarily adopted consistency in terms may seem to be > an overly ambitious goal, but I think even incremental progress is > worth achieving. > > We should not even attempt to achieve the level of mandated > consistency seen in fields like medical encoding (HL7, MEDRA, ICD-10, > etc.), but as a professional user of those sorts of controlled > vocabularies and ontologies, there are elements those approaches to > knowledge representation that are worth emulating on a smaller scale. > > > cjl -- Gil Forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net planet: http://planet.guifi.net _______________________________________________ gnome-i18n mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-i18n
