Thanks for keeping on with this, Bruno. :)
On 05/04/2005, at 5:21 AM, Bruno Haible wrote:
> Some of this may be covered by the tutorial that has been added in
> gettext 0.14.3.
Um, tutorial? Where would that be?
> What else is missing?
> I'm really bad at writing documentation. If someone could help me=20
I'd write it, if I knew what to put in. However, it helps if you have a=20=
thorough understanding of something before writing about it. :(
> In fact, what do you translators need to know? Do you need to know
> the context of a message (error message, confirmation message, etc.),
> or the types of things that get stuffed into format strings (like
> "the first %s is a filename, the second %s is an error message"), or
> what else?
Basically, as far as I've been able to see, we need to know the=20
practical steps that need to be taken in order to do our job. Those=20
could be linked back to the manual, so we have the basics to do our=20
job, but can get more info when we need it. Each section below could=20
contain links to the manual for additional info. That's where it is,=20
but we don't always know where to find it, nor do we always have the=20
time (or perhaps the inclination :) ) to look.
As to what we need to know, that rests on what you want us to do. I=20
would guess at (but I don't know much, so please add anywhere):
1. So you want to translate a .po file. Simple description of format=20
and why that makes life easier.
2. Get the file. Need for latest files. Brief sketch of different=20
methods of doing this, and links to main projects' howtos on this.=20
3. New file? Populate it from your compendium. Brief instructions.=20
Shared glossaries. Link to manual for more.
4. Updated file? Does it need msgmerge-ing with previous file? You may=20=
wish to populate remaining strings from your compendium. Quick howto.
5. Fix the headers. Empty model, fixed model, inc brief description of=20=
why each header is important. Links to how to do this in Emacs, Kbabel=20=
etc., other resources, e.g. strftime string for auto-revision date.
6. Translate/edit the file. Model of empty string block and completed=20
string block, with brief description of structure. Link to manual for=20
7. Style tips: e.g. the things the robot is trying to achieve
8. Error in msgid string? Contact developer using address from=20
Report-Msgid-Bugs-To header. Header not there? See textual domain. No=20
good? Google using this structure. Quick tips, e.g. all gnu bugs=20
addresses follow format X.
9. Not sure about this string? Contact developer as above. Discuss with=20=
team or on language forum. Quick resources for this.
10. You survived the process? Congratulations. Now you come in for the=20=
merciless picky nature of the TP robot. Checklist. How to submit the=20
11. Quick tips on how to automate the repeat process, make life easier.
12. Further resources, inc. more manual links.
I think I know how to explain these things in a basic fashion. How=20
about I do that, then bring back the result to this group, and you guys=20=
can decide what to add? I can't do this for the developer, but perhaps=20=
you could use my very simple structure as a start, just look at the=20
must-do developer things.
I rather enjoy explaining things, being a teacher by vocation, so I'd=20
like to have a go, then you guys could work out what's missing from my=20=
skeleton structure. You'll find out how little your day-to-day=20
translator can actually know. :)
from Clytie (vi-VN, team/nh=C3=B3m Gnome-vi)
Clytie Siddall--Renmark, in the Riverland of South Australia
=E1=BB=9E th=C3=A0nh ph=E1=BB=91 Renmark, t=E1=BA=A1i mi=E1=BB=81n s=C3=B4=
ng c=E1=BB=A7a Nam =C3=9Ac=