Display or DBase issue? Retrieval of data

Asked by Harald Franzen on 2014-02-06

Running Ubuntu 13.10, Gourmet 0.16.1 and MySQL server 5.1.73 on a remote server (LAN).

I have setup Gourmet Recipe Manager so it stores its data through MySQL on a remote server, accessible for multiple clients.

Entering data works like a charm. I can easily add recipies that are then stored in the database. Using MySQL Workbench under Linux, as well as through phpmyadmin, I can verify that all data is correctly stored in the correct collation.

However, when I open recipe cards, some will not show all the data (often the preparation method is not visible, less often the instructions AND the ingredients, even less often nothing at all), some will open up perfectly, showing all the data previously entered. What I do notice is that the application remains seems to be busy (I see Ubuntu's equivalent of the hour glass). Interestingly enough, they are always the same recipies that show up perfectly as well as the same recipies that seem to be missing data... (consistent behaviour).

Then, thinking I might have forgotten to add the instructions, when I try to change instructions (or ingredients for that matter), the window that opens does not show all the tabs the "original" window showed when I entered the data, so there is for example no tab to add/alter instructions.

However, if I add ANY recipe to the grocery list (my most important requirement), that works perfectly, even if the recipe card does not display ANY info (no title, no ingredients, no instructions). Again: all the data that is not showing is perfectly stored in the MySQL database and seems to be queried correctly once I add a recipe to the grocery list.

What am I overlooking here? Do not hesitate to ask for error logs (if any exist; where would I find those?).

Thanks for your response!

Question information

Language:
English Edit question
Status:
Solved
For:
Gourmet Edit question
Assignee:
No assignee Edit question
Solved by:
Harald Franzen
Solved:
Last query:
Last reply:

This question was reopened

Revision history for this message
Bernhard Reiter (ockham-razor) said :
#1

Please run gourmet from a Terminal, try to reproduce those issues you described, and paste the error messages you get on the terminal here.

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#2

Thanks, Bernhard! I should have thought of that myself :-(

This is what I did:
gourmet --database-url=mysql://XXX:YYY@ZZZ/gourmetrecipe > Gourmet.log

The program started and in the recipe list, I browsed one page to open the recipe card for one of the recipes I knew would show the issue. I opened this one recipe, then closed it and closed the program.

Below, I have posted both the terminal output as well as the contents of "Gourmet.log" (see the command above).
I left out the login information out of the logs, but both registered it correctly in compliance with the (anonymised) version above.

The logs show at least an issue with utf-8 encoding. As an example in the terminal output:
[quote]
GError: Fout in regel 1 teken 722: Ongeldige UTF-8-gecodeerde tekst - niet geldig
[/quote]
Which, translated into English, would read something like
"GError:Error in line 1 character 722: Invalid UTF-8-encoded text - invalid".

But also color marking goes awry (if an instruction contains, "cook for 10 minutes", I noticed the software will add a hyperlink to the countdown-timer and will effectively mark it as such (color blue and underline):
[quote]
/usr/lib/python2.7/dist-packages/gourmet/reccard.py:252: GtkWarning: Failed to set text from markup due to error parsing markup: Attribute 'kleur' is not allowed on the <span> tag on line 1 char 56
[/quote]
"Kleur" is Dutch for color.

At the end of "Gourmet.log", there's a problem with "Escaping text".

Anyway, we do use heaps of those diacritical characters like ë é è ê à and so on, both in Dutch (our native language) as well as in some of the recipes, like the French "vélouté de cèpes" :-)

A work around could be to remove all those, but I wonder why on input all goes well and on output it doesn't.

I do apologize for the horrid mix of English, French and Dutch below!

Best regards,
Harald

This is the terminal output:

/usr/lib/python2.7/dist-packages/gourmet/shopgui.py:202: GtkWarning: Invalid input string
  self.ui_manager.ensure_update()
/usr/lib/python2.7/dist-packages/gourmet/recindex.py:122: RuntimeWarning: missing handler 'ingmen_clear'
  'search_as_you_type_toggle' : self.toggleTypeSearchCB,})
/usr/lib/python2.7/dist-packages/gourmet/recindex.py:122: RuntimeWarning: missing handler 'ingmen_pantry'
  'search_as_you_type_toggle' : self.toggleTypeSearchCB,})
/usr/lib/python2.7/dist-packages/gourmet/recindex.py:122: RuntimeWarning: missing handler 'print'
  'search_as_you_type_toggle' : self.toggleTypeSearchCB,})
/usr/lib/python2.7/dist-packages/gourmet/recindex.py:122: RuntimeWarning: missing handler 'email'
  'search_as_you_type_toggle' : self.toggleTypeSearchCB,})
/usr/lib/python2.7/dist-packages/gourmet/recindex.py:122: RuntimeWarning: missing handler 'batch_edit'
  'search_as_you_type_toggle' : self.toggleTypeSearchCB,})
/usr/lib/python2.7/dist-packages/gourmet/recindex.py:122: RuntimeWarning: missing handler 'rl_delrec'
  'search_as_you_type_toggle' : self.toggleTypeSearchCB,})
/usr/lib/python2.7/dist-packages/gourmet/recindex.py:122: RuntimeWarning: missing handler 'rl_viewrec'
  'search_as_you_type_toggle' : self.toggleTypeSearchCB,})
/usr/lib/python2.7/dist-packages/gourmet/recindex.py:122: RuntimeWarning: missing handler 'rl_shoprec'
  'search_as_you_type_toggle' : self.toggleTypeSearchCB,})
/usr/lib/python2.7/dist-packages/gourmet/GourmetRecipeManager.py:699: PangoWarning: Invalid UTF-8 string passed to pango_layout_set_text()
  gtk.main()
/usr/lib/python2.7/dist-packages/gourmet/reccard.py:252: GtkWarning: Failed to set text from markup due to error parsing markup: Attribute 'kleur' is not allowed on the <span> tag on line 1 char 56
  self.ui.add_from_file(os.path.join(uibase,'recCardDisplay.ui'))
/usr/lib/python2.7/dist-packages/gourmet/reccard.py:259: RuntimeWarning: missing handler 'rcHide'
  'edit_modifications': lambda *args: self.reccard.show_edit(module='notes'),
/usr/lib/python2.7/dist-packages/gourmet/reccard.py:392: GtkWarning: Failed to set text from markup due to error parsing markup: Attribute 'kleur' is not allowed on the <span> tag on line 1 char 56
  self.window.add(main_vb); main_vb.show()
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/TextBufferMarkup.py", line 77, in set_text
    self.parsed,self.txt,self.separator = pango.parse_markup(txt,u'\x00')
GError: Fout in regel 5 teken 16: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘600 g c�pes
3 stuks knoflookteen
60 g boter (zout)
15 cl slagroom
5 cl olijfolie’
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 472, in update_from_database
    module.update_from_database()
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 676, in update_from_database
    self.display_ingredients()
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 721, in display_ingredients
    self.ingredientsDisplay.set_text(label)
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/LinkedTextView.py", line 51, in set_text
    PangoBuffer.set_text(self,txt)
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/TextBufferMarkup.py", line 82, in set_text
    self.parsed,self.txt,self.separator = pango.parse_markup(txt,u'\x00')
GError: Fout in regel 5 teken 16: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘600 g c�pes
3 stuks knoflookteen
60 g boter (zout)
15 cl slagroom
5 cl olijfolie’
/usr/lib/python2.7/dist-packages/gourmet/reccard.py:559: GtkWarning: Failed to set text from markup due to error parsing markup: Fout in regel 1 teken 33: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘Velout� de c�pes’
  self.titleDisplay.set_label(titl)
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/TextBufferMarkup.py", line 77, in set_text
    self.parsed,self.txt,self.separator = pango.parse_markup(txt,u'\x00')
GError: Fout in regel 5 teken 16: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘600 g c�pes
3 stuks knoflookteen
60 g boter (zout)
15 cl slagroom
5 cl olijfolie’
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 623, in yields_change_cb
    self.ingredientDisplay.display_ingredients() # re-update
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 721, in display_ingredients
    self.ingredientsDisplay.set_text(label)
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/LinkedTextView.py", line 51, in set_text
    PangoBuffer.set_text(self,txt)
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/TextBufferMarkup.py", line 82, in set_text
    self.parsed,self.txt,self.separator = pango.parse_markup(txt,u'\x00')
glib.GError: Fout in regel 5 teken 16: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘600 g c�pes
3 stuks knoflookteen
60 g boter (zout)
15 cl slagroom
5 cl olijfolie’
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/TextBufferMarkup.py", line 77, in set_text
    self.parsed,self.txt,self.separator = pango.parse_markup(txt,u'\x00')
GError: Fout in regel 1 teken 722: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘S�parer la t�te du pied des c�pes. A l�aide de papier absorbant, essuyer le chapeau. Retirer l�extr�mit� du pied et l��plucher finement. D�tailler les champignons en d�s. Hacher l�ail.Dans une po�le antiadh�sive faire suer les champignons avec un peu d�huile. Egoutter. Mettre � cuire les champignons dans une po�le, ajouter l�ail, le sel et le poivre. Laisser revenir environ 5 mn puis couvrir d�eau froide. Porter � �bullition puis laisser cuire environ 20 mn � feu moyen, en couvrant la casserole.A la fin de la cuisson, mixer une premi�re fois. Hors du feu, ajouter la cr�me et une noix de beurre. Mixer � nouveau jusqu�� obtenir un m�lange onctueux. Laisser mijoter environ 5 mn � feu tr�s doux.Servir chaud.’
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gourmet/GourmetRecipeManager.py", line 1132, in show
    w=reccard.RecCard(self, rec)
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 75, in __init__
    self.show()
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 127, in show
    self.show_display()
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 102, in show_display
    self.recipe_display = RecCardDisplay(self, self.rg,self.current_rec)
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 186, in __init__
    self.update_from_database()
  File "/usr/lib/python2.7/dist-packages/gourmet/reccard.py", line 502, in update_from_database
    widg.set_text(attval)
  File "/usr/lib/python2.7/dist-packages/gourmet/timeScanner.py", line 33, in set_text
    make_time_links(txt)
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/LinkedTextView.py", line 51, in set_text
    PangoBuffer.set_text(self,txt)
  File "/usr/lib/python2.7/dist-packages/gourmet/gtk_extras/TextBufferMarkup.py", line 82, in set_text
    self.parsed,self.txt,self.separator = pango.parse_markup(txt,u'\x00')
glib.GError: Fout in regel 1 teken 722: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘S�parer la t�te du pied des c�pes. A l�aide de papier absorbant, essuyer le chapeau. Retirer l�extr�mit� du pied et l��plucher finement. D�tailler les champignons en d�s. Hacher l�ail.Dans une po�le antiadh�sive faire suer les champignons avec un peu d�huile. Egoutter. Mettre � cuire les champignons dans une po�le, ajouter l�ail, le sel et le poivre. Laisser revenir environ 5 mn puis couvrir d�eau froide. Porter � �bullition puis laisser cuire environ 20 mn � feu moyen, en couvrant la casserole.A la fin de la cuisson, mixer une premi�re fois. Hors du feu, ajouter la cr�me et une noix de beurre. Mixer � nouveau jusqu�� obtenir un m�lange onctueux. Laisser mijoter environ 5 mn � feu tr�s doux.Servir chaud.’
/usr/lib/python2.7/dist-packages/gourmet/reccard.py:320: GtkWarning: Failed to set text from markup due to error parsing markup: Fout in regel 1 teken 33: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘Velout� de c�pes’
  widget.set_label(t)

This is the output in "Gourmet.log"

We have a db_url and it is, mysql://XXX:YYY@ZZZ/gourmetrecipe

Problem encountered escaping text: "Doe alle ingrediënten in de kom van bijvoorbeeld een KitchenAid of broodbakmachine. Kneed er in ongeveer <span underline="single" color="blue">10 minuten</span> een soepel deeg van. Overdoen in een ingevette kom.1e rijs: <span underline="single" color="blue">1 - 1 1/2 uur</span>.Verdeel dan met een deegsteker het deeg in 12 - 14 gelijke stukjes en maak er bolletjes van. Leg ze op een bakplaat.2e rijs: ongeveer <span underline="single" color="blue">1 uur</span>.Verwarm tijdens het laatste kwartier van de rijstijd de oven voor op 200 °C. Bestrijk voor 'boterbolletjes' de gerezen bolletjes met gesmolten roomboter, voor 'zadenbroodjes' bestrijken met losgeklopt ei/melkmengsel en bestrooien met sesamzaad of maanzaad.In <span underline="single" color="blue">12 - 15 minuten</span> gaar en bruin bakken. Bestrijk de 'boterbolletjes' direct na het afbakken weer met gesmolten roomboter. Af laten koelen op een rooster."
Problem encountered escaping text: "100 g zalm, gerookt
20 g spinazie, blad
75 g kruidenkaas
1 eetlp. bieslook
2 eetlp. crème fraîche"
WARNING: Exception raised by <gourmet.reccard.IngredientDisplay instance at 0x4a2df80>.update_from_database()
Problem encountered escaping text: "100 g zalm, gerookt
20 g spinazie, blad
75 g kruidenkaas
1 eetlp. bieslook
2 eetlp. crème fraîche"
Problem encountered escaping text: "Meng een Boursin 2 lepels crème fraîche en wat bieslooksnippers tot een smeuïge, homogene mengeling.Leg de plakjes zalm uit en leg er wat blaadjes spinazie in.Leg nu de mengeling van de Boursin er op.Rol de zalm op met behulp van bakpapier en leg de rollen, gewikkeld in het papier, enkele uren in de diepvriezer.Even voor het serveren haalt u de rollade uit de diepvriezer en snijdt u er kleine rondjes van.Leg de hapjes op een schotel en versier met enkele snippers sinaasappelschil of wat bieslook"

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#3

Just to add a little word.
I had one recipe in English (usually without é, è and so on), that didn't show its instruction properly. Using appropriate database tools, I found out that the very last sentence was in Dutch, using the word "ingrediënten" (note the ë in there). Replaced it with a normal e and voilà; it turns op perfectly.
Also, the issue of not being able to edit the instructions and/or not getting the various tabs on the recipe card whilst editing, had been resolved for that recipe.
So the diacritical marks seem to be the culprit. The MySQL-collation is: UTF-8 Unicode (utf8), the MySQL connection collation: utf8_general_ci and the database tables: utf8_general_ci.

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#4

And here the locale settings for the local workstation:
LANG=nl_NL.UTF-8
LANGUAGE=nl:en_GB:en
LC_CTYPE="nl_NL.UTF-8"
LC_NUMERIC=nl_NL.UTF-8
LC_TIME=nl_NL.UTF-8
LC_COLLATE="nl_NL.UTF-8"
LC_MONETARY=nl_NL.UTF-8
LC_MESSAGES="nl_NL.UTF-8"
LC_PAPER=nl_NL.UTF-8
LC_NAME=nl_NL.UTF-8
LC_ADDRESS=nl_NL.UTF-8
LC_TELEPHONE=nl_NL.UTF-8
LC_MEASUREMENT=nl_NL.UTF-8
LC_IDENTIFICATION=nl_NL.UTF-8
LC_ALL=

Revision history for this message
Thomas M. Hinkle (thomas-hinkle) said :
#5

It seems from this thread like the recipes are being stored correctly but
storage is breaking with unicode pulled from MySQL -- is that right? Can
you confirm that the MySQL DB has the information stored in it perchance?

The other thing you could do to check is try accessing those recipes in
another way -- printing or exporting them, for example, or using the
experimental web-based interface if that's packaged w/ Gourmet (I forget if
it's in the plugins directory we ship out or not). There's a decent chance
one of those methods will display the data that gets broken on the way to
the GUI, though of course that depends on where the bug is occurring. I can
confirm that using the SQLite database, I am able to save and display
accented characters w/ no problem.

Tom

On Fri, Feb 7, 2014 at 11:31 AM, Harald Franzen <
<email address hidden>> wrote:

> Question #243472 on Gourmet changed:
> https://answers.launchpad.net/gourmet/+question/243472
>
> Harald Franzen gave more information on the question:
> And here the locale settings for the local workstation:
> LANG=nl_NL.UTF-8
> LANGUAGE=nl:en_GB:en
> LC_CTYPE="nl_NL.UTF-8"
> LC_NUMERIC=nl_NL.UTF-8
> LC_TIME=nl_NL.UTF-8
> LC_COLLATE="nl_NL.UTF-8"
> LC_MONETARY=nl_NL.UTF-8
> LC_MESSAGES="nl_NL.UTF-8"
> LC_PAPER=nl_NL.UTF-8
> LC_NAME=nl_NL.UTF-8
> LC_ADDRESS=nl_NL.UTF-8
> LC_TELEPHONE=nl_NL.UTF-8
> LC_MEASUREMENT=nl_NL.UTF-8
> LC_IDENTIFICATION=nl_NL.UTF-8
> LC_ALL=
>
> --
> You received this question notification because you are a member of
> Gourmet Recipe Manager, which is an answer contact for Gourmet.
>

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#6

Thank you Tom!

You pointed in the right direction so I managed to resolve it. The cause is in the MySQL server settings.

This might touch other users too choosing a MySQL-database for Gourmet, so I will post the solution here for those users that run into the same trouble. Feel free to reuse in wiki or FAQ.

This solution is at least valid for the following configuration:
Gourmet 0.16.1
Client: Ubuntu 13.10
Server: Ubuntu 10.04.4 LTS
MySQL-server: 5.1.73 on a remote server (Ubuntu 10.04.4 LTS).

By default, a MySQL server, once installed, will use the latin1-collation as the server collation. Even if all other collations are set to utf8, you might suffer when using diacritical marks, like é ö à when using a MySQL database for Gourmet.

Open an appropriate tool for your MySQL-database like phpmyadmin and execute the following query:
[code]
SHOW VARIABLES LIKE 'char%';
[/code]

The output will look like this:
[code]
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysqld/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)
[/code]

Note the variable: "| character_set_server | latin1 | "

In Ubuntu (use appropriate commands for your OS) login to the server environment (via SSH for example) and execute the following command to stop the MySQL-server. I have posted the commands for an Ubuntu server below; use appropriate commands for your server-OS.
[code]
sudo service mysql stop
[/code]

Edit the my.cnf file:
[code]
sudo nano /etc/mysql/my.cnf
[/code]

Find the section named [mysqld] and add the following:
[code]
character-set-server=utf8
skip-character-set-client-handshake
[/code]

Save my.cnf

Start the server:
[/code]
service mysql start
[code]

Verify the changed setting by executing the same query:
[code]
SHOW VARIABLES LIKE 'char%';
[/code]

Job done! Gourmet should now now longer struggle displaying diactritical marks.

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#7

Now the issue seems to be reversed; stored recipes with diacritical marks work perfectly, but I cannot seem to store recipes with diacritical marks :-(

I will investigate and see if I can find out why...

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#8

These are the errors I am getting when entering diactritical marks and trying to save. Suggestions are welcome:

/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py:324: Warning: Incorrect string value: '\xE8me fr...' for column 'item' at row 1
  cursor.execute(statement, parameters)
/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py:324: Warning: Incorrect string value: '\xE8me' for column 'word' at row 1
  cursor.execute(statement, parameters)
/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py:324: Warning: Incorrect string value: '\xEEche' for column 'word' at row 1
  cursor.execute(statement, parameters)

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#9

And the solution is to force the connection to use utf8, so your connect string for Gourmet should read:

gourmet --database-url=mysql://USER:PASSWORD@SERVER/DATABASENAME?charset=utf8

where, USER, PASSWORD, SERVER and DATABASENAME are your specific parameters.

Revision history for this message
Bernhard Reiter (ockham-razor) said :
#10

Good thing you solved it yourself! Now ideally, I'd like to solve this by programmatically forcing that setting, but of course, we have no influence on people's MySQL collation settings. Could you check if it also works if you reset those to latin1?

-------- Ursprüngliche Nachricht --------
Von: Harald Franzen <email address hidden>
Datum:
An: <email address hidden>
Betreff: Re: [Question #243472]: Display or DBase issue? Retrieval of data

Question #243472 on Gourmet changed:
https://answers.launchpad.net/gourmet/+question/243472

    Status: Open => Solved

Harald Franzen confirmed that the question is solved:
And the solution is to force the connection to use utf8, so your connect
string for Gourmet should read:

gourmet --database-
url=mysql://USER:PASSWORD@SERVER/DATABASENAME?charset=utf8

where, USER, PASSWORD, SERVER and DATABASENAME are your specific
parameters.

--
You received this question notification because you are a direct
subscriber of the question.

Revision history for this message
Bernhard Reiter (ockham-razor) said :
#11

BTW, as for that "kleur" issue, that's a bug in the Dutch translation file (where someone accidentally translated HTML attribute names and values to Dutch). Fixed now by https://github.com/thinkle/gourmet/commit/b0c30d56fe834f312fa17380bdea90d0ad9b01d1

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#12

Hello Bernhard,

There were TWO issues involved.

The first is the MySQL-setting, that should be resolved in ANY utf-8 environment. The reason for the latin1 as the server collation is a silly one; originally, MySQL was developed by a Swedish company, and they used latin1 for their diacritical marks. The web has 100s of pages on this issue, but one is used to find most stuff in utf8 these days, so one tends to overlook it.

The second issue was the parsing of the text by SQLAlchemy; it doesn't use utf-8 by default, but unicode (if I have understood correctly; I am not a programmer). This discrepancy causes the requirement to force the engine to use utf8 on startup.

Only then is all the traffic between the application and the data store streamlined into utf8 only and all will work correctly.

It would be a long shot trying to solve this programmatically (not trying to diminish your capabilities); once a user starts deploying a MySQL database for Gourmet (as opposed to a user that will be happy to do the standalone using SQLAlchemy and the default SQLite3 database), they will be probably be sufficiently adept to follow the necessary instructions to correctly setup those two parameters.

A good FAQ should do the trick, I think :-)

Can I assist with the Dutch translations in any way? There's a little typo when you edit a recipe: the button to edit the notes reads "Notiities bewerken" (the English will probably read: "Edit notes"). That's a small typo: it should read "Notities bewerken" (note on 'i' less in the correction). There's also a few translations missing here and there.

Revision history for this message
Bernhard Reiter (ockham-razor) said :
#13

Sorry, I didn't make myself clear enough. I was curious if things would keep working for you if you kept the charset=utf8 SQLAlchemy connection parameter, but switched back MySQL's character_set_server setting to latin1. I'm not sure if the latter is really needed, provided that charset=utf8 is passed to SQLAlchemy (especially when creating a new MySQL database). To me, character-set-server looks more like an internal setting telling MySQL how to store (text) data internally (see http://dev.mysql.com/doc/refman/5.0/en/charset-configuration.html), but I believe there's a chance that MySQL is able to process and output UTF-8 properly anyway, *if* that charset=utf8 parameter is passed (which we can also do programmatically, BTW).

As for translating, help is greatly appreciated! Our translations are actually done here on Launchpad (see the "Translations" link on top of this page -- Dutch would be at https://translations.launchpad.net/gourmet/main/+pots/gourmet/nl/+translate). It's up to us maintainers to regularly sync them with the code at GitHub, so don't be surprised if your changes don't show up there immediately. As for "Notiities", I've just fixed them in git. There's one more spot where language-specific things are stored: the defaults files, e.g. for Dutch see https://github.com/thinkle/gourmet/blob/master/gourmet/defaults/defaults_nl.py

Revision history for this message
Harald Franzen (harald-franzen-lotcavediving) said :
#14

That is fair comment Bernhard. I stand corrected.

I reverted the server back to the original settings, so the variable "character-set-server" is back to latin1 (verified it before proceeding).
Then I started Gourmet with the connect string forcing the utf8 collation and then it works perfectly as well.
Tried entering a test recipe with heaps of ééé and àà and so on and it stores correctly in the MySQL database and is retrieved correctly as well.
Again, I am not a programmer, but maybe forcing utf8 in the connect string will cause issues for those that are not in a utf8-environment?

As for the translations: I'll make sure to give it a go. There seems to have been a Flemish person involved in translating too, because I see plenty of terms that are actually Flemish, not Dutch. Strangely enough, we share the same dictionary, but the languages are not entirely identical; much like British English and American English. Are there any guidelines I should follow? For example, I see an ingredient named "witloof" (which is very Flemish) which in Dutch (and in our shared dictionary of the Dutch language) is actually called "witlof" (so one "o" less). We'd all understand the term, but Dutch would either see this as a spelling error or understand it's a Belgian that did the translating :-) Same for "selder" which would read "selderij" in Dutch.

As I have a practical use case for this software, I might be able to give you some input as well on the user-side of things as well; let me know -maybe through PM- if you guys would be interested.

Cheers,

Harald

Revision history for this message
Bernhard Reiter (ockham-razor) said :
#15

Thanks for testing! You're right, we need to make sure that forcing utf8 won't cause any issues, but I'm optimistic that it will work (I'll try it with the default SQLite backend for starters).

As for the Dutch/Flemish situation, that's something very familiar for this Austrian ;-) Fortunately, that's something that gettext (the underlying translation framework) supports, and we even have nl_BE.po (and de_AT.po) files (in https://github.com/thinkle/gourmet/tree/master/po), so it's possible to give different translations for language variations, but those latter files don't seem to be mapped to Launchpad right now -- obviously, Flemish should go to nl_BE.po, which would probably show up in Launchpad as "Dutch (Belgium)", while standard Dutch should be contained in nl.po. I'll need to investigate this a bit, as uploading our current set of *.po files from git to Launchpad last night failed with a timeout (plus I need to make sure not to override translations from Launchpad by blanks from git, but OTOH keep fixes -- like the "kleur" and "notiities" stuff), and loading some of Lanchpad's translation pages still takes forever...

So what you could do instead for now is install a translation files editor like poedit (which is what I use) from the Ubuntu Software Center and work on nl.po directly (don't use nl_NL.po, I'd like to remove that one -- as well as e.g. de_DE.po and pt_PT.po -- as those are redundant). Are you familiar with git? Ideally you could fork the git repo on GitHub and clone it locally, work on the file, push it to your fork and submit pull requests. But if that whole git workflow is new to you, I don't want to force it on you -- you can just download the current nl.po from the GitHub location noted above, work on it, and send it to me.

I'm very interested in field experience from users -- feel free to either PM me, or maybe better yet, sign up for our team and (very, very low traffic) mailing list at https://launchpad.net/~gourmet and post it there.

Revision history for this message
Bernhard Reiter (ockham-razor) said :
#16

Now about those Flemish or German Austrian translations not showing up in Launchpad, that's really strange as they are apparently there -- they're just not listed, see e.g. https://translations.launchpad.net/gourmet/main/+pots/gourmet/nl_BE/+translate
(Just posted https://bugs.launchpad.net/launchpad/+bug/1278065)