Compose, dialogue logic and translatable strings

[Kai Willadsen]

The attached patch only touches TagWindow.C, and does several things:

* It marks some strings as translatable (everything I could find in
TagWindow.C).
* It moves some stuff around to avoid including markup in translatable
messages, like:
<b>All</b>
is now
String::ucompose ("<b>%1</b>", _("All"))
* Where possible, it changes GtkMessageDialogs to use the automatic
markup scheme by removing markup on the primary message and using
set_secondary_text().
* It cleans up some of the dialogue logic for single/multiple cases.
As best as I can tell, the logic is identical, except for a
"docselectionignore_ = false;" statement, which to my reading has no
effect. However, these parts would benefit from someone else reading
them over.

It *doesn't* fix other things:
* I haven't ucompose-d or marked anything not in TagWindow.C. I know
that Transfer.C, Library.C and DocumentProperties.C contain 1 or 2
translatable strings each, but nothing big.
* The functions Utility::exceptionDialog and TagWindow::ensureSaved
will need to change significantly in order to not break translation.
At the moment, they assume English-like grammar. Therefore, I haven't
ucompose-ified them, and haven't marked any of their strings (or
strings passed to them) for translation.
* There are several situations where ngettext should probably be used,
but by i18n-foo isn't really good enough to understand that properly.

I realise that the patch does several only-slightly-related things, so
if you want it broken up, let me know.

Kai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-and-marking-translations.patch
Type: text/x-patch
Size: 16686 bytes
Desc: not available
URL: <http://icculus.org/pipermail/referencer/attachments/20070314/2f7d14b3/attachment.bin>

[John Spray]

Post by Kai Willadsen
* It marks some strings as translatable (everything I could find in
TagWindow.C).
* It moves some stuff around to avoid including markup in translatable
<b>All</b>
is now
String::ucompose ("<b>%1</b>", _("All"))
* Where possible, it changes GtkMessageDialogs to use the automatic
markup scheme by removing markup on the primary message and using
set_secondary_text().
* It cleans up some of the dialogue logic for single/multiple cases.
As best as I can tell, the logic is identical, except for a
"docselectionignore_ = false;" statement, which to my reading has no
effect. However, these parts would benefit from someone else reading
them over.

Have reviewed this and committed it with one or two tweaks.

I couldn't see your patch doing anything to the docselectionignore
lines, but anyway I read it over and nothing leaps out at me as being
wrong.

Post by Kai Willadsen
* I haven't ucompose-d or marked anything not in TagWindow.C. I know
that Transfer.C, Library.C and DocumentProperties.C contain 1 or 2
translatable strings each, but nothing big.

Indeed.

Post by Kai Willadsen
* The functions Utility::exceptionDialog and TagWindow::ensureSaved
will need to change significantly in order to not break translation.
At the moment, they assume English-like grammar. Therefore, I haven't
ucompose-ified them, and haven't marked any of their strings (or
strings passed to them) for translation.

Yes, I kind of realised this was going to be a problem eventually (I'm
pleasantly surprised by how soon I've had interest from translators!).
What can I say, I was in a hurry when I wrote it ;-)

Post by Kai Willadsen
* There are several situations where ngettext should probably be used,
but by i18n-foo isn't really good enough to understand that properly.

Mine neither.

Post by Kai Willadsen
I realise that the patch does several only-slightly-related things, so
if you want it broken up, let me know.

In general I'd prefer if logic changes such as those for the dialogs
were in isolated patches, but I'm not picky enough to send it back.

Thanks for the patch.

John

[Claudius Wilhelms]

Hi John,

after being isolated from internet for three weeks, I can report now my experiences with the use of referencer for my quite big and various collection of literature.

Referencer is working quite good. When importing 1000+ files "at one click", it crashed a few times, but I think that is a unusual special case.
I'm _VERY_HAPPY_ with referencer, but I quickly realised that for organising whole libraries, two additional features would be great:

1.)
mass-editing of bibtex fields
Inspired from these nifty ID3-tag renaming tools for mp3s, I would highly appreciate such a function for bibtex editing as well.
For example, I came back from a polymer conference with 20 presentations that were held there on my laptop.
I added the universal tag "polymer" for these documents easily. But How can I separate them from my other polymer-related documents ? I can use proposal 2 (see below), but even nicer would be to edit some bibtex fields for these files at once, e.g. to put in the name of the conference, the date and the type of paper.


2.) Multiple instances of tags
This can be found in f-spot and allows you to realize a nice tag-structure easily.

Regards,

Claudius

[John Spray]

Post by Claudius Wilhelms
Referencer is working quite good. When importing 1000+ files "at one
click", it crashed a few times, but I think that is a unusual special
case.
I'm _VERY_HAPPY_ with referencer, but I quickly realised that for

Did you get a crash dialog when it crashed? Reports of such things are
appreciated.

Post by Claudius Wilhelms
1.)
mass-editing of bibtex fields
Inspired from these nifty ID3-tag renaming tools for mp3s, I would
highly appreciate such a function for bibtex editing as well.

Mmm, for bulk-setting journal/author this can be useful. Patches
welcome.

Post by Claudius Wilhelms
For example, I came back from a polymer conference with 20
presentations that were held there on my laptop.
I added the universal tag "polymer" for these documents easily. But
How can I separate them from my other polymer-related documents ?

I would expect you to have one tag called polymer, another called
"PolymerConf07", and those from the conference would have both tags,
while other polymer docs would only have the first.

Post by Claudius Wilhelms
2.) Multiple instances of tags
This can be found in f-spot and allows you to realize a nice
tag-structure easily.

I'm not sure what you mean. You already get multiple tags on one
document.

John

[Kai Willadsen]

Post by John Spray

Post by Kai Willadsen
* I haven't ucompose-d or marked anything not in TagWindow.C. I know
that Transfer.C, Library.C and DocumentProperties.C contain 1 or 2
translatable strings each, but nothing big.

Indeed.

The attached patch fixes all of the remaining simple cases that I could find.

There is still a fair bit of hard-coding style stuff in one place. How
would you feel about doing a GtkMessageDialog-style API for things
like ExceptionDialog and getRemoteFile. For example, getRemoteFile
could take title, primary and secondary text and do the markup itself.
(I'm not necessarily volunteering to do this, just thinking aloud.)

Post by John Spray
In general I'd prefer if logic changes such as those for the dialogs
were in isolated patches, but I'm not picky enough to send it back.

Yeah, sorry about that. I realised the compose problem when reworking
the dialogue logic, thus the confusion.

Kai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: more-compose.patch
Type: text/x-patch
Size: 6901 bytes
Desc: not available
URL: <http://icculus.org/pipermail/referencer/attachments/20070316/4e27338b/attachment.bin>

[Claudius Wilhelms]

Hi John,

sorry, i forgot to attach that console output lines (see below). AFAIR, there have been some non-pdf files in my folder that referencer didn't like.

Accordung to your reply: #
- I'm not a programmer (only fortran, scilab and other technical stuff), so I'm not able to sumbit patches, sorry... How much effort would it be to implement a mass-editing of bibtex fields ?

- Multiple instances of tags: The possibility to create subtags like that:
tag:polymer
|-tag:conference07
|-tag:meeting06

OK, keep up the good work and nice to see that the mailing list is quite active !

Claudius



console output:

Warning: DocumentList::getDoc: couldn't find doc with name 'Weichgummierun'
Document::readPDF: Loaded, extracting text...

(Referencer:7344): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g_convert_error
code : 1
what : Ung?ltige Bytefolge in Konvertierungseingabe



Error: Document has not the mandatory ending %EOF
Document::readPDF: Failed to load '/home/claudius/Desktop/Literatureingang (Kopie)/Poster/061102 PTJ Statusseminar Freiburg/tmp/fuer PTJ Poster/Bildschirmfoto-18.png'
Warning: DocumentList::getDoc: couldn't find doc with name 'Bildschirmfoto-9'
Couldn't find thumbnail:'file:///home/claudius/Desktop/Literatureingang%20(Kopie)/Poster/061102%20PTJ%20Statusseminar%20Freiburg/tmp/fuer%20PTJ%20Poster/141205%20ST-VL3.odp'
Generate thumbnail: 'file:///home/claudius/Desktop/Literatureingang%20(Kopie)/Poster/061102%20PTJ%20Statusseminar%20Freiburg/tmp/fuer%20PTJ%20Poster/141205%20ST-VL3.odp'

(process:12049): Gdk-CRITICAL **: gdk_screen_get_root_window: assertion `GDK_IS_SCREEN (screen)' failed

(process:12049): Gdk-CRITICAL **: gdk_pixmap_new: assertion `(drawable != NULL) || (depth != -1)' failed

(process:12049): Gdk-CRITICAL **: gdk_gc_new: assertion `drawable != NULL' failed

(process:12049): Gdk-CRITICAL **: gdk_pango_context_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed