Several changes to how Drupal handles the list of available languages (previously called locales).

 - migrated 'locales_meta' table to 'languages' table
 - added new language properties (native language name, direction, weight)
 - modified locale tables to reflect key change in languages table

 - new menu structure for language management and locales

 - new language detection subsystem
   - new bootstrap phase
   - different language negotiation options
   - language based URL rewrite (path prefix and domain support)

 - migrating to the successor RFC 4646 from ISO 639 codes (backwards compatible)

 - fix small bugs in string seeking and editing

 - language dependant URL alias support (this can be postponed to a separate patch if required)

For more information about the changes and grab a fully patched Drupal from Subversion, see http://groups.drupal.org/i18n
Please provide feedback!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

FileSize
4 KB

Here is the required (new) language.inc file.

Steven’s picture

I like where this is going... looks very promising.

I'll take a more thorough look later, but some quick things on a scroll through:

+  $ret[] = update_sql("DROP TABLE {locales_meta");

missing bracket.

And various code style spacing issues.

Dries’s picture

I already reviewed previous versions of this work. I'll let the others review this first. It's important work, so I hope we can get some decent reviews soon. I'd like to see us move forward with this.

I'm particularly interested in learning more about people's feedback about the UI changes (and the new terminology used at these UIs).

Dries’s picture

-    "he" => array("Hebrew", "עברית"),
+    "he" => array("Hebrew", "עברית", 1),

looks broken ...

Gábor Hojtsy’s picture

Dries, that line is not broken. If you see how the bytes are ordered on that line, you will see the quotes and the ordering are right. Because Hebrew chars indicate right-to-left ordering, it is displayed differently, but the code is fine. Look at it in mcedit, or some more bare bones viewer/editor.

killes@www.drop.org’s picture

I've looked at it and didn't find anything that I particularly disliked.

You should probably add Arab to the rtl languages.

Steven’s picture

Gabor: would it help if we add a unicode directional override in a comment before and after that list?

killes@www.drop.org’s picture

Steven: yes

Gabor: And please do patches with cvs diff -up

Steven’s picture

FileSize
94.48 KB

Updated the patch with a LTR marker before each right-to-left language name. This should make the code appear correctly in all editors, both for the entire file as well as for patches.

I didn't change any other things though.

AmrMostafa’s picture

subscribing..

SloMo’s picture

There are missing curly braces in line 1468:

+  $default = db_fetch_object(db_query('SELECT * FROM locales_meta WHERE isdefault = 1'));

Line 1471 (already pointed out by Steven) is missing a closing curly brace:

+  $ret[] = update_sql("DROP TABLE {locales_meta");

That's it so far.

Gábor Hojtsy’s picture

FileSize
94.48 KB

OK, fixed the two curly brace problems identified. Thanks Steven for identifying RTL languages :)

hass’s picture

i have downloaded 6.0-dev and applied the patch. after patching i cannot install from scratch. everytime an error:

PHP Warning: require_once(./includes/bootstrap.inc) [function.require-once]: failed to open stream: Permission denied in C:\Inetpub\wwwroot\drupal6\index.php on line 12 PHP Fatal error: require_once() [function.require]: Failed opening required './includes/bootstrap.inc' (include_path='.;C:\php5\pear') in C:\Inetpub\wwwroot\drupal6\index.php on line 12 
hass’s picture

sorry, something was rotten with exclusive file access... this problem is solved now. but another bug comes up after i created a new language and then pressed "save".

On my box and in the patch it looks like you missed to include "/includes/language.inc" !?

PHP Warning: include_once(./includes/language.inc) [function.include-once]: failed to open stream: No such file or directory in C:\Inetpub\wwwroot\drupal6\includes\bootstrap.inc on line 948 PHP Warning: include_once() [function.include]: Failed opening './includes/language.inc' for inclusion (include_path='.;C:\php5\pear') in C:\Inetpub\wwwroot\drupal6\includes\bootstrap.inc on line 948 PHP Fatal error: Call to undefined function language_initialize() in C:\Inetpub\wwwroot\drupal6\includes\bootstrap.inc on line 949

Gábor Hojtsy’s picture

hass, the language.inc file is up here in the issue, but not included in the patch.

douggreen’s picture

I'm at the hackfest reviewing this patch. Rather than submit everything en-mass, I'll add comments as I find them.

The confirm delete code needs reworked. When you try to delete a language locale_admin_manage_delete_form doesn't actually delete the form. The function provides a confirm_form, but when the user confirms the delete, they end up back in this function and get asked to confirm the delete again.

I think all it's missing is a submit handler definition. I have a patch for this, but will wait to post it until the end of the day, in-case I have additional fixes to add to it.

douggreen’s picture

When you try to export a language using admin/build/locale/string/export, FAPI goes recursive somehow related to the #options in _locale_export_po_form sending the language opject. I've patched it to send the array keys rather than the object, and it no longer goes recursive, but I'm not sure if this loses any behavior.

douggreen’s picture

I exported both es (Spanish) and he (Hebrew) from admin/build/locale/string/export The Hebrew export contained lots of translations, but the spanish export did not. I'm not sure yet if anything is wrong here, but it seemed odd that one language exported lots of string translations and another one did not.

#  translation of Drupal
# Copyright (c) 2007 admin <douggreen@douggreenconsulting.com>
#
msgid ""
msgstr ""
"Project-Id-Version: PROJECT VERSION\n"
"POT-Creation-Date: 2007-03-25 15:56-0400\n"
"PO-Revision-Date: 2007-03-25 15:56-0400\n"
"Last-Translator: admin <douggreen@douggreenconsulting.com>\n"
"Language-Team:  <douggreen@douggreenconsulting.com>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"
douggreen’s picture

On the user edit page, there's a missing argument to variable_get('language_count') on locale.module +149 that causes a php error -- the default language_count should be set to 1.

douggreen’s picture

Also on the user edit page, when the user hasn't selected a language, they should get the system default. There are actually two changes needed for this:

  1. In bootstrap.inc, when building the language_list('enabled'), then language should be added as a key to the array. Currently it just appends to the array, and thus the indexes are [0], [1], etc... language_from_browser in language.inc also relies on the enabled list to return an array of keys rather than numbers
  2. in locale.module, the default language needs to be set from language_default() rather than from languages array, because the list isn't sorted with any knowledge of the default language.
douggreen’s picture

When the site wide language negotiation is anything except _PATH the user preferences are ignored. Thus, the user form should only set this value when the site wide negotiation is LANGUAGE_NEGOTIATION_PATH. I have a patch for this that I'll include with my end of day upload.

douggreen’s picture

FileSize
366.19 KB

Uploading a consolidated patch for all my comments above.

douggreen’s picture

FileSize
3.97 KB

Also uploading a new language.inc that has two extraneous break statements removed...

douggreen’s picture

FileSize
98.58 KB

Please ignore the previously uploaded patch file and use this one instead. Sorry :(

chx’s picture

FileSize
94.39 KB

confirm_form is broken from #base, patch is in queue , so I removed that submit handler.

Dries’s picture

Status: Needs review » Fixed

Committed to HEAD! :-)

Gábor Hojtsy’s picture

Status: Fixed » Reviewed & tested by the community

Dougs site configs slipped in with this patch.
http://cvs.drupal.org/viewcvs/drupal/drupal/sites/default/settings.php?r...
Dries tried to fix this by reverting some stuff, but he did not revert the safe mode setting, and did not revert the site name to example.com (left it at localhost), plus did not add a # as it was commented out. All these should be reverted.

Gábor Hojtsy’s picture

FileSize
3.74 KB

Patch attached to fix the following issues:
- settings.php inadvertent commit (revert to previous version)
- array_keys() only listed the language codes on the export page (and was added by Doug because of an infinite loop produces by formapi). Now provide a proper fix for that, also reusing functionality in locale module as possible. The export page lists language names again.

hass’s picture

Status: Reviewed & tested by the community » Needs work

you last patch is missing a bugfix doug introduced...

$db_url = 'mysql://doug:civicactions@localhost/doug_drupal6_lang';

no good idea to post passwords... hopefully only used once :-)

hass’s picture

Status: Needs work » Reviewed & tested by the community

oh, has already been patched in CVS...

douggreen’s picture

Big apologies for this. Luckily the passwords are only for my local host and for this particular install.

Gábor Hojtsy’s picture

FileSize
17.22 KB

Chx and Angie reported a few issues to my by mail, which popped up through the "kitchen sink" collaboration, so here is an updated patch, including the previous fixes and some new ones.

Fixes for:
- settings.php inadvertent commit (revert to previous version)
- proper fix for the export and import pages UI to list language names as previously
- add plurals, formula, enabled and other properties to the default lanuage, so code depending on those values will not throw notices
- rename the "langname" and "langnative" form field names to "name" and "native", so conversion to and from DB data is easier (was a code cleanup requirement for the above fix)
- check for an uploaded file in PO import, and emit error message, staying on the same page, when no file was found
- fix notice generating reuse of PO and POT generation submit handlers
- remove a bunch of notices in PO export (formula and header nonexistent, no translation for some strings)
- inform users when the locale string search yielded no results (this was very confusing before, and reported by Angie as well)
- fix string search help display on the upper tab too

Dries’s picture

Status: Reviewed & tested by the community » Needs work

Patch doesn't seem to apply ...

Maybe include http://drupal.org/node/131583 and http://drupal.org/node/131640 as well?

Dries’s picture

Also, let's add some information to CHANGELOG.txt. :-)

Gábor Hojtsy’s picture

Status: Needs work » Needs review
FileSize
19.89 KB

Patch updated to latest HEAD, folded those two patches in, modification of CHANGELOG.txt included.
Setting to "needs review, so Steven can come in and discuss the theme related change".

Dries’s picture

I've committed this patch already but I'm leaving it as 'code needs review' so we can discuss this further, and follow up with incremental patches.

hass’s picture

importing German results in

# notice: Undefined variable: file in C:\Inetpub\wwwroot\drupal6\includes\locale.inc on line 912.
# notice: Trying to get property of non-object in C:\Inetpub\wwwroot\drupal6\includes\locale.inc on line 912.
# notice: Trying to get property of non-object in C:\Inetpub\wwwroot\drupal6\includes\locale.inc on line 977.
# notice: Trying to get property of non-object in C:\Inetpub\wwwroot\drupal6\includes\locale.inc on line 977.
# notice: Trying to get property of non-object in C:\Inetpub\wwwroot\drupal6\includes\locale.inc on line 977.
# notice: Trying to get property of non-object in C:\Inetpub\wwwroot\drupal6\includes\locale.inc on line 977.
# notice: Trying to get property of non-object in C:\Inetpub\wwwroot\drupal6\includes\locale.inc on line 977.
and so on and so on...
hass’s picture

maybe related:

URL: http://localhost/drupal6/index.php?q=admin/build/block

PHP Fatal error: Call to undefined function menu_get_root_menus() in C:\Inetpub\wwwroot\drupal6\modules\menu\menu.module on line 119

Gábor Hojtsy’s picture

hass, the $file variable issue already has a patch for Drupal 5.x-dev, and as soon as that is comitted, I will port it to Drupal 6.x-dev.
Issue: http://drupal.org/node/72564

erdemkose’s picture

Deleting the default language doesn't set a new default language. This causes some errors to be displayed. Attached patch avoids the deletion of default language as we do for English.

Steven’s picture

Status: Needs review » Needs work

The patch does not conform to code style regarding indentation or spaces. There's also some existing errors in the affected lines. Let's weed those out.

Gábor Hojtsy’s picture

Status: Needs work » Needs review
FileSize
2.74 KB

I was unable to find any "existing errors", but fixed what I have seen in there within the changes (also the error message wording).

Dries’s picture

Status: Needs review » Fixed

Tested. Works for me.

Anonymous’s picture

Status: Fixed » Closed (fixed)
bjaspan’s picture

Status: Closed (fixed) » Needs work

Unless I'm mistaken this patch does not have a working upgrade path. The new version of locales_target has a column named 'language' but the update function does not create the column on existing tables. When updating from a D5 database, the column is never created.

This causes system_update_6019() (pending, Schema API patch) to fail:

user warning: Key column 'language' doesn't exist in table query: ALTER TABLE locales_target ADD INDEX language (language) in C:\Documents and Settings\bjaspan\Home\WORK\drupal\head\includes\database.mysqli.inc on line 154.

Failed: ALTER TABLE {locales_target} ADD INDEX language (language)

Incidentally, I also noticed that in locale_update_6002(), case 'mysql' calls db_add_column() but that function is defined specifically to work with pgsql. Are the mysql and pgsql cases reversed?

Gábor Hojtsy’s picture

Indeed, the locales_source and locales_meta tables were not changed in locale_update_6001(), but should have been. This was an oversight. The 'locale' column was renamed to 'language' by the way, this is not a new column technically.

Also, locale_update_6002() seems to have the mysql and pgsql cases mixed up.

Would be nice if someone could provide a patch, since I try to work with feature patches now that the code freeze is so close on us.

Gábor Hojtsy’s picture

Huh, also noticed that the variables table got a language field inadvertently with the first patch being committed.

Now committed a fix with the following:
- reversed the mysql and pgsql cases in locale_update_6002()
- removed the language column from the variable table

The column renaming issues in locales_source and locales_target still stand, would be nice if someone could pick them up (they are not that trivial to commit right away).

Gábor Hojtsy’s picture

Status: Needs work » Needs review
FileSize
775 bytes

Barry, does something guarantee that locale module updates will run before system module updates? If not, system_update_6019() will fail everytime, as the locale module tables are not yet updated at the time.

BTW here is a patch which changes the column in locales_target, which should fix this. I noticed both postgresql and mysql had *differently named* indexes for the locale field in Drupal 5. I see the MySQL case is covered in system.install, but pgsql is not. How should we go about this? What happens to the index if we rename the column? I suppose it's name will stay the same (bogusly in pgsql). It seems to be odd that system.install interfers with our (locale.module) schema, but anyway, we should sort out how these work together.

Gábor Hojtsy’s picture

Barry it would be nice if you could reply to my concerns so we can have an updateable locale module in core.

Gábor Hojtsy’s picture

FileSize
778 bytes

Updated patch for locale module changed. Awaiting Barry's comments.

bjaspan’s picture

Barry, does something guarantee that locale module updates will run before system module updates? If not, system_update_6019() will fail everytime, as the locale module tables are not yet updated at the time.

It seems to be odd that system.install interfers with our (locale.module) schema, but anyway, we should sort out how these work together.

No, nothing guarantees that, just the normal module weight,name sort order. system_update_6019() tries to fix the locale stuff only because it tries to fix everything that isn't fixed somewhere else. If it makes more sense to move those updates into locale.install, by all means do so.

I noticed both postgresql and mysql had *differently named* indexes for the locale field in Drupal 5. I see the MySQL case is covered in system.install, but pgsql is not.

There were several such cases; there was never any consequence before of having differently named indexes, so they occurred. If I fixed it mysql and not pgsql, it is because the pgsql index was already named as the pgsql schema driver wants it. At least, that was my intention.

What happens to the index if we rename the column?

On pgsql, they get dropped. db_update_field() in database.pgsql.inc takes care of re-creating them, but it relies on accessing your own hook_schema() output from an update function which is generally a no-no (but I *think* is safe in this one case). At any rate, other update code is using db_update_field(). You could just drop the index, rename the column, and re-create the index manually; there are API calls for those operations. I'd recommend that.

Gábor Hojtsy’s picture

Barry I honestly don't understand this completely. Here is an updated patch. I did move the column rename code to the locale update, so it happens there, and we have control over the field rename.

You said that the pgsql code recreates the index, but I would still better drop and create it. What about the mysql case? We need to rename the index in mysql, but not in pgsql as it seems. Do we need to drop the index for mysql only and create it for both databases? I honestly don't understand...

You had some good insight into these schemas when you did the update patch, so I would really feel helped out if you could give this some more thought, and help figure this out. I don't think a broken schema (as now in HEAD), or as possibly a result of my attached patch committed is any good.

hass’s picture

i thought the new schema systems is database independed!? now you have build a mysql detection inside the update. This cannot be correct, while schema API should know what to do or not with the indexes, whatever db servers it sees, isn't it? i don't know all about this new schema system, but this cannot be the intention...

Gábor Hojtsy’s picture

Hass the mysql dependent code in the patch was directly moved from the mysql dependent schema migration update from system.install. There were some schema differences, which needed to be leveled, and there we had differently named indexes for the locale field of locales_target, so we while we rename the fields, we need to deal with the indexes too. This is an interim update between the schema API and the previous DB dependent SQL stuff (which made the index naming inconsistencies possible in the first place).

catch’s picture

Status: Needs review » Needs work

patching file modules/locale/locale.install
Hunk #1 succeeded at 115 (offset 5 lines).
patching file modules/system/system.install
Reversed (or previously applied) patch detected!

Not sure if this is still valid or not.

moshe weitzman’s picture

Anything left to do here?

bjaspan’s picture

The last time I tried to upgrade the locale module from D5 to D6 it did not work so I have left it disabled in all of my upgrade testing. #55 implies that we still do not have a working patch. I'll try to look into this again.

Gábor Hojtsy’s picture

Barry, this would be greatly appreciated. The locale update works fine on MySQL luckily, so we just need to match up the pieces.

JirkaRybka’s picture

FYI - this: http://drupal.org/node/157682 is where I slipped in *some* fix for the locale upgrade path, which seems to work for me still. Note that part of it is inside update.php rather than .install files, because otherwise there were tons of warnings all through the update.

But I seem to remember there's some index difference (index in schema, but not created on update), which I'm going to open an issue for, as soon as I have time to re-discover which one it is.

Gábor Hojtsy’s picture

Marked http://drupal.org/node/191236 as duplicate of this issue, and asked JirkaRybka to chime in here.

JirkaRybka’s picture

Status: Needs work » Needs review
FileSize
721 bytes

OK, let's see what I have to say here:

The patch #52 is totally outdated now, because:

- There's another locale_update_6005() now,

- The field-renaming operation was already included into update_fix_d6_requirements() - see http://drupal.org/node/157682 fixing the upgrade path more than 2 months ago - to avoid warnings early in update.php. This involves adding a new column (avoiding warnings without of breaking previous Drupal version usability), migrating data ( locale_update_6002() ) and dropping the old column.

- Along with the old column, in locale_update_6002() the index gets dropped too (I believe; however inconsistent it might be), so all we need to do now is to create the index on the new column. This is what my patch does.

Moving the patch from http://drupal.org/node/191236 - attached here.

Gábor Hojtsy’s picture

Assigned: Gábor Hojtsy » Unassigned

Great, I think the analysis and the patch looks fine, but at least one more pair of eyes would be great on this. Ie. Barry or someone else to review. Anyway, if they are not screaming on the patch in a day or two, I'll commit it.

bjaspan’s picture

[ Note: I have not yet applied the latest patch in this thread. No time at this moment, so this comment will serve as a pre-patch status report. ]

I changed my upgrade test system to use Drupal 5.3 with all optional core modules enabled, including locale, whereas previously I did not have locale enabled. On running the D5 to D6 upgrade with pgsql, I received:

* warning: pg_query() [function.pg-query]: Query failed: ERROR: syntax error at or near "s" at character 8 in C:\Documents and Settings\bjaspan\Home\WORK\drupal\head\includes\database.pgsql.inc on line 155.
* user warning: query: DELETE s FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid WHERE t.lid IS NULL in C:\Documents and Settings\bjaspan\Home\WORK\drupal\head\modules\locale\locale.install on line 113.

I think that should be "DELETE FROM" not "DELETE s FROM".

After the update, schema.module reports these inconsistencies:

* locales_source
o indexes source:
declared: array(array('source', 30))
actual: array('source')
*locales_target
o indexes language: missing in database

Gábor Hojtsy’s picture

Title: New language subsystem » Locale update path broken in postgresql
Category: task » bug
Priority: Normal » Critical

bjaspan: Thanks for testing, greatly appreciated.

The DELETE issue is not easily resolved with removing the "s", as this is a DELETE FROM ... JOIN statement which does not seem to be supported by PostgreSQL (http://www.postgresql.org/docs/8.3/static/sql-delete.html). Well, another unfortunate MySQL specific query in core. Seems like PostgreSQL supports subselects in DELETEs though, so we could do:

DELETE FROM locales_source WHERE lid NOT IN (SELECT lid FROM locales_target)

By the looks, this does the same as the query it would replace. Basically, the goal is to remove all source rows which have no target rows related. So remove all source rows with lids not present in the target table. By the way, this query was suggested in http://drupal.org/node/171646 by JirkaRybka, and I committed his patch, without PostgreSQL testing obviously.

JirkaRybka's latest patch here seems to fix the missing language index (by the looks), so apart from fixing this query, we also need to fix the source index and all should look fine, judging from the pre-patch status report.

(Status elevated, title updated).

Gábor Hojtsy’s picture

Status: Needs review » Needs work

Forgot to set "needs work".

JirkaRybka’s picture

The delete query - OOPS and big sorry! I consulted every bit of documentation I could while suggesting that, and it seemd like being the only and fully legal solution back then. I don't have pgsql. Now checking the MySQL manual at http://dev.mysql.com/doc/refman/5.0/en/subqueries.html, the Gábor's query seems to be supported (since 4.1, which is now required for Drupal), I'll test as soon as possible (no promises for today) and update my patch accordingly.

The locales_target index should be now fixed by the patch here. Testing welcome.

The locales_source index doesn't occur on MySQL, so I have no chance for testing. Can someone help with this one, please? It seems that only the length of that index is different.

bjaspan’s picture

It looks to me like both databases support DELETE ... USING. I haven't tried it to see if it works, though.

JirkaRybka’s picture

Status: Needs work » Needs review
FileSize
1.02 KB

OK, now attaching a new patch. This one might fix all the three problems, but DEFINITELY NEEDS SOME PGSQL TESTING!

The DELETE problem: I did a bit of research on web, and found three queries:
1. DELETE s FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid WHERE t.lid IS NULL
2. DELETE FROM s USING {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid WHERE t.lid IS NULL
3. (thanks a lot to Gábor's #64) DELETE FROM {locales_source} WHERE lid NOT IN (SELECT lid FROM {locales_target})
All three are working fine on my MySQL 4.1.19 install, with exactly the same results and similar speed.

As for PgSQL compatibility, I am only able of some wild guesses based on web documentation (which is not that verbose on PgSQL, seems to me), I never laid hands on PgSQL install really, but I seem to gather that:
1. is most recommended on MySQL http://dev.mysql.com/doc/refman/5.0/en/delete.html but #63 proves it incompatible with PgSQL. This is the current implementation in locale_update_6005().
2. is also recommended on MySQL (the same page), and seems vaguely supported on PgSQL (as far as I can tell from the documentation available), except that this page: http://www.postgresql.org/docs/8.3/static/sql-delete.html mentions USING in a DELETE context being PgSQL extension (!) even on newest 8.3 version (!). So this seems to me awfully unsafe bet.
3. is supported on MySQL ( http://dev.mysql.com/doc/refman/5.0/en/any-in-some-subqueries.html ), although not mentioned directly on DELETE page (which confused me back then), and seems to be also supported on PgSQL - this use case nowhere explicitly mentioned, but basically seems listed at http://www.postgresql.org/docs/7.4/interactive/features.html (supported features for PgSQL 7.4, which is Drupal 6 minimum).

So the new patch contains 3. and needs PgSQL testing urgently.

locales_target index is probably covered by the patch already.

locales_source index: I included some code that might work, but again - no PgSQL testing done. #63 shows, that index name is consistent, only it's length is not. So this patch includes (PgSQL only) dropping and re-creating of the index. I tested on MySQL (with the switch construct commented out - otherwise no need to run this on MySQL) and the index was re-created correctly.

Also looking into a 5.3 locale.install, it seems to me like there's no such index on locales_source for PgSQL? Am I missing something? (But anyway, we're risking maximally one failed DROP query, the index should then be created OK.)

bjaspan’s picture

Status: Needs review » Reviewed & tested by the community

With this patch applied, a D5.3 install with the locale module enabled upgrades cleanly to D6 HEAD on mysql and pgsql (modulo recently introduced schema inconsistency bugs in block and search not related to this issue). Note that my 5.3 system contained no locale data but as far as schema consistency and update.php, this patch passes.

JirkaRybka’s picture

bjaspan: Thanks a LOT for testing!

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Superb, committed. Thanks.

JirkaRybka’s picture

Title: Locale update path broken in postgresql » New language subsystem (plus update fix)

Resetting original title for future reference.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.