Mantis bugtrack

Linux-haladó

Helló!

Adott egy Gentoo Linux alatt üzemelő 1.0.6-os Mantis bugtrack rendszer. Ha a felhasználó beállítja magyar nyelvűre a felhasználói felületet, akkor a feliratok rendesen magyarul jelennek meg. Ha magyarul ír, akkor a hosszú ő és a hosszú ű kivételével minden karakter normálisan jelenik meg.
Használ még valaki Mantis-t? Sikerült-e valakinek rábírnia a teljes ékezethelyes (ő, ű) működésre?

üdv,

Ábrahám Péter

  • 5088 megtekintés

( Emulgeator | 2007. 01. 03., sze – 16:35 )

nalunk muxik rendesen, de ne kerezd hogyan, nem en csinaltam :)

( Vendor v | 2008. 01. 17., cs – 14:11 )

en a lang/strings_english -ben atirtam $s_charset = 'UTF-8'; -ra (angolul hasznaljuk, de elojott az ekezet bug)

( BeR | 2008. 04. 23., sze – 07:19 )

Nekem a tegnap délutánom/estém ment rá, hogy a Mantis ő-ű kezelését körbejárjam (komolyabb PHP és MySQL gyakorlat nélkül). Kukkoltam a neten, de valós válaszra nem leltem, így maradt a kisérleti számítástechnika. Ubuntu 7.10-es szerver a cél-os, amin alap PHP, MySQL, phpMyAdmin van telepítve. Mivel az itthomi tesztgépen 7.04 megy amióta van, upgrade-eltem 7.10-re (simán ment) Két csomag bevezetés előtti kipróbálása, megismerése a cél: egy belső információ-tárházat kezelő MediaWiki, és egy hibakövető Mantis.

Mindkét rendszer szépen felment, üzemel, ám míg a MediaWiki ékezetei helyesek, a Mantis hibázik az Ő-Ű-nél :-( A kotorászás eredménye: bár a MySQL-ben utf8 a default, mindkét sw text mezői latin1_swedish_ci kódolásúak: ennek ellenére a MediaWiki-ben jó az Ő-Ű, a Mantisban nem. Tettem egy póbát: egy user mezőt átállítottam, s lássatok csodát, előjöttek az elveszett ékezetek...

Ez lenne a megoldás?

BeR

Úgy gondolom, rájöttem a hiba (lehetséges) okára: a MySQl szerver globális karakter típusa latin1_swedish_ci volt, amikor a Mantist telepítettem. Mivel a Mantis telepítője az adatbázis karaktertípusát nem szabja meg, olyan lesz, amilyen. Most tettem egy próbát a következőkkel a my.cnf-et a következő értékekkel:

default-character-set=utf8
character_set_server=utf8
collation_server=utf8_general_ci

Ezek után a mysqld-t, telepítettem egy új Mantist: minden szövegmező UTF és helyes ékezetek jelennek meg.

BeR

Ez frankó. Utólag hogy lehetne ezt kivitelezni?
Elég tetemes mennyiségű adat van már a mantis -ban, amit mi használunk, de nálunk is rosszalkodnak az ékezetek. A mysql latin1 -et használ jelenleg. Ha azt átállítanám most utf8 -ra, akkor a későbbi hibajegyek tutira jól jelennének meg, de a jelenlegiek meg elcsúsznának, nem?

--
http://laszlo.co.hu/

Hali...

Kipróbáltam azt is, hogy kézzel egy-egy mezőt átírtam "utf-generic-ci"-re, s a mantis "kezelte", nem jött hibaüzenet...

A migráción most ügyködök, lehet kipróbálom, amit itt tanácsoltak...
(nálam még csak kevés anyag van benne, mert az ékezet miatt nem indultunk el, de jól jöhet még)

BeR

A régi - rossz őűŐŰ - adatok migrálására a következőt próbáltam ki, s működött (lehet, h csacskaság is van benne):

  • A régi bugtracker DB mentése: 
    mysqldump -u root -p -c -B --add-drop-table --add-locks bugtracker --default-character-set=utf8 >mbt_latin2.sql

  • Másolatot csináltam az SQL-ről mbt_utf8.sql néven
  • Az SQL fájlban a táblák create-jeinek végén lévő
    CHARSET=latin1

    beállításokat átírtam 

    CHARSET=utf8

    -ra

  • Visszatöltöttem az adatokat: 
    mysql -u root -p < mbt_utf8.sql

  • Beléptem a mantisba, s nálam jól kezeli ezek után az ékezeteket.

Ami nekem nem volt tiszta a fentieken kívül: az SQL-ekben UTF8-as stringek is voltak (kipróbáltam 

--default-character-set=utf8-generic-ci

nélkül is, de akkor is így volt), ami szvsz (talán) azért volt, mert a korábban írtak szerint a mysql beállításait átírtam.

BeR

( lyken | 2009. 05. 20., sze – 20:32 )

Na, akkor még egy módszer.
Én is szórakoztam egy kicsit a dologgal. Nekem nem volt kedvem dumpolni, úgyhogy kimásoltam egy spreadsheet-re phpmyadmin alól a táblák neveit a második oszlopba.
Első oszlopba beírtam, hogy 'ALTER TABLE ' harmadik oszlopba beírtam, hogy ' CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;' Mindkettőt értelemszerűen végighúztam lefele, amíg táblanév volt.
Az egészet kimásoltam egy txt-be, majd onnan ment phpmyadmin "Run SQL query/queries on database" box-ba, nyomtam egy go-t és átállt minden.

Mantis 1.1.7 esetében a konkrét eredmény, amit lefuttatva utf8-as lesz:

ALTER TABLE mantis_bugnote_text_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_bug_file_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_bug_history_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_bug_monitor_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_bug_relationship_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_bug_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_bug_tag_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_bug_text_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_config_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_custom_field_project_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_custom_field_string_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_custom_field_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_email_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_filters_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_news_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_project_category_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_project_file_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_project_hierarchy_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_project_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_project_user_list_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_project_version_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_sponsorship_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_tag_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_tokens_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_user_pref_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_user_print_pref_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_user_profile_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE mantis_user_table CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

Mi beuzemeltuk, de rogton belefutottunk ebbe az ekezet levagasba; mivel az egesz plugin erosen alpha es maga az 1.2-es mantis is rc meg, igy nem foglalkoztunk a temaval. Peldanak okaert szep kis bug jelenleg az is, hogy nem lehet megmondani egy postafiokbol behuzott levelek celja egy alprojekt legyen... Roviden: felejtos. Majd ha lesz final release, adunk neki ujabb eselyt.

( zoner | 2009. 10. 28., sze – 22:41 )

Kérdés: létezik-e olyan Mantis szerű BT, amiben ha épp nem hibajegyeket küldenek be, be tudom írni, hogy az új feature leprogramozása X idő volt és utána ezeket valamilyen módon kezeli is? mantishoz a kommentekhez lehet írni Timestampot, de az kicsit buta és nincs több értelme, mint hogy a komment mellé oda lesz írva az idő.