Re: Repetitive strings in many modules

[Gil Forcada <gforcada gnome org>]

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 <gforcada gnome org> 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