? ???, 30/12/2008 ? 12:38 +0100, Marco Ciampa ?????:

i.e. in file

po/it/menus/colors/auto.po

there are these strings:

msgid "$Revision: 2315 $" msgstr ""

That can be translated, though such string can be removed from the source xml.

should not be handled automatically?

#: src/menus/colors/auto.xml:15(date) msgid "2007-10-17"
msgstr ""

This must be translated and it's not easy to do this automatically. For example US people will prefer to see 10/17/2007 here. In Russian it must be something like 17-10-2007.

as above...

#: src/menus/colors/auto.xml:16(authorinitials) msgid "ude"
msgstr ""

meaning of this?

It's the name

how are supposed to be translated and why?

Ude? Some languages prefer translated (transliterated) names as well.

Marco Ciampa (Dienstag, 30. Dezember 2008, 12:38):

msgid "$Revision: 2315 $"
msgstr ""

[...]

msgid "2007-10-17"
msgstr ""

[...]

msgid "ude"
msgstr ""

meaning of this?

These are the entries of --..

how are supposed to be translated and why?

Add your authorinitials and the date when you edited the po file?

But IMHO we should just remove these entries from the source files. They don't contain any essential information, do they?

BTW, it seems that we did not use these tags correctly: "RevHistory is a structure for documenting a history of changes,..." (DocBook: The Definitive Guide),
a is meant to contain a set of tags - see the example in DTDG.

We just replaced the revision entries whenever we edited the xml file, but does such an entry really mean anything?

Bye, Ulf

These are the entries of --..

how are supposed to be translated and why?

Add your authorinitials and the date when you edited the po file?

But IMHO we should just remove these entries from the source files. They don't contain any essential information, do they?

Perhaps users reading the HTML files want to know when the text has been updated and who updated it?
But the is of no use. Can we delete it keeping the rest?

Julien

julien (Mittwoch, 31. Dezember 2008, 16:11):

Perhaps users reading the HTML files want to know when the text has been updated and who updated it?

If the date is e.g. 2006-xx-yy or 2009-xx-yy, what do you (or what does the user) *really* know? For instance, is this text up-to-date?

The release date of the gimp-help package is probably more helpful.

But the is of no use. Can we delete it keeping the rest?

According to DTDG, only is required, everything else is optional, so we can remove .

I still think we should remove the entries, maybe adding a instead, which will be expanded by SVN to

Ulf

Perhaps users reading the HTML files want to know when the text has been updated and who updated it?

If the date is e.g. 2006-xx-yy or 2009-xx-yy, what do you (or what does the user) *really* know? For instance, is this text up-to-date?

The last GIMP release was a few monthes ago. If the date is 2006-xx-yy, then this file has not been updated. When I review files for v2.6, I always give a new date, even if there is no change in the file.

The release date of the gimp-help package is probably more helpful.

The last gimp-help-package is 2.4, out of date. Now GIMP has an online help, with the present status of the help ( well, when our po system is OK ;-) .)

But the is of no use. Can we delete it keeping the rest?

According to DTDG, only is required, everything else is optional, so we can remove .

Good, I'll do that.

I still think we should remove the entries, maybe adding a instead, which will be expanded by SVN to

If you like. But an hour with seconds... :-(

Julien

Hi,

I still think we should remove the entries, maybe adding a instead, which will be expanded by SVN to

What is interesting for users is "Has the information in this file changed or been updated?".

We must distinguish: - "semantic" changes, bringing new information . update to v2.6
. correction of errors

- "formal" changes, not bringing new information . typos corrections
. rewriting the text for better understanding without adding any new information.
. changes in xml structure

It seems that your $id$ proposition doesn't distinguish this.

I propose to add two new at the top of files, showing "semantic" changes, that will appear in the html:

subcript>File updated to v2.6 on ... by ... subcript>File improved on ... by ... and perhaps also:
subcript>File translated to ... on ... by ...

because this information must be unobstrusive in the HTML file. An interest is that these can be translated in all languages, avoiding english in localised html.

"Formal" changes remain in the commented "Section history"

Julien

julien (Donnerstag, 1. Januar 2009, 20:22):

The last GIMP release was a few monthes ago. If the date is 2006-xx-yy, then this file has not been updated.

What if someone just didn't update the revision entry? Maybe nothing changed, so the file is still up-to-date. But what might the user think when he reads "2006"?

When I review files for v2.6, I always give a new date, even if there is no change in the file.

That sounds reasonable, although it's probably not the intended usage.

The release date of the gimp-help package is probably more helpful.

The last gimp-help-package is 2.4, out of date.

Yes, and today the (online or offline) manual *is* out of date...

I still think we should remove the entries, maybe adding a instead, which will be expanded by SVN to

If you like. But an hour with seconds... :-(

If you don't like it, just don't read it. ;-)

Ulf

julien (Freitag, 2. Januar 2009, 08:36):

I still think we should remove the entries, maybe adding a instead, which will be expanded by SVN to

What is interesting for users is "Has the information in this file changed or been updated?".

We must distinguish: - "semantic" changes, bringing new information . update to v2.6
. correction of errors

- "formal" changes, not bringing new information . typos corrections
. rewriting the text for better understanding without adding any new information.
. changes in xml structure

It seems that your $id$ proposition doesn't distinguish this.

Yes, it's just the information (for documenters or translators) who committed when any changes.

I propose to add two new at the top of files, showing "semantic" changes, that will appear in the html:

subcript>File updated to v2.6 on ... by ... subcript>File improved on ... by ... and perhaps also:
subcript>File translated to ... on ... by ...

because this information must be unobstrusive in the HTML file. An interest is that these can be translated in all languages, avoiding english in localised html.

IMHO a nice idea. :-) However,
(a) at the top the reader should find the most important information (summary, screenshot, previews, etc.), so this new para should go the bottom of the (HTML) file;
(b) is definitely the wrong way to add a para using a tiny font; the correct method is: hmm, I have no idea... ;-) (passing an attribute to HTML?)

Ulf

Hi,

I still think we should remove the entries, maybe adding a instead, which will be expanded by SVN to

What is interesting for users is "Has the information in this file changed or been updated?".

We must distinguish: - "semantic" changes, bringing new information . update to v2.6
. correction of errors

- "formal" changes, not bringing new information . typos corrections
. rewriting the text for better understanding without adding any new information.
. changes in xml structure

It seems that your $id$ proposition doesn't distinguish this.

Yes, it's just the information (for documenters or translators) who committed when any changes.

I propose to add two new at the top of files, showing "semantic" changes, that will appear in the html:

subcript>File updated to v2.6 on ... by ... subcript>File improved on ... by ... and perhaps also:
subcript>File translated to ... on ... by ...

because this information must be unobstrusive in the HTML file. An interest is that these can be translated in all languages, avoiding english in localised html.

IMHO a nice idea. :-) However,
(a) at the top the reader should find the most important information (summary, screenshot, previews, etc.), so this new para should go the bottom of the (HTML) file;
(b) is definitely the wrong way to add a para using a tiny font; the correct method is: hmm, I have no idea... ;-) (passing an attribute to HTML?)

There is a better solution : adding a in the revision.

2009-01-04 ude
Updated to v2.6

Instead of "Updated to v2.6", we can have "Improved". ( an indivible space (AltGr+Shift+space) is necessary before this text for alignment with data above).

And we must decide that the information in "revision" is intended for users (they appear in the html). All other information, intended for doc writers, must be in the commented "Section history".

I'll apply this in my next patch.

Julien