Not being able to translate Page & Story links

Is this still valid? A couple days ago, a patch went in to create these at install time, with t()s in place.

meba, can you give us steps to reproduce this bug?

I was unsure about translation issues myself, so I asked meba in IRC for some more info.

Basically, if you look at this .po file, you'll see the following:

#: modules/system/system.install:3254
msgid "Story"
msgstr "Článek"

#: modules/statistics/statistics.module:234;261;291
#: modules/system/system.install:3245
msgid "Page"
msgstr "Stránka"

The problem is, because those strings are defined, it should be using them when you click "Create content" but it isn't.

I'm not sure we can fix this... the user can define any content type, we can't provide translations for all of them. An admin in another language should just translate his content type names directly in the UI, not use .po files for it. But, perhaps we can add a hack to the install.php locale where it can provide localized version of default variables and set ups.

If you actually want multiple languages for your content type names, then you have to use i18n. I imagine this is yet another feature to be added to its responsibilities as CCK comes into core.

Would wrapping these in st() rather than t() make sense? Then whatever the installer version of the language would catch it?

Or am I talking out of my ass again? ;)

@webchick - That sounds like my ass talk you've stolen!

Marking normal priority since you can just use the UI to rename the posts.

Maybe I am missing something, but the strings are simple not wrapped in t() at all. The patch solves the issue for me (tested with German localization).

Right, description also needs to be translated and the title on node/add/xxx pages too. Patch updated.

1. We have a rule in Drupal to use t() for literal strings. Please do not wrap variable strings in t() unless you are absolutely sure that it comes from a literal string elsewhere. Please do not accept patches to t() node type names and descriptions in runtime, if we are still obeying this rule (and we do as far as I know). This rules out profix898's patches.

2. Story and Page are default node types added into the database before translations can be imported (unless you use the autolocale module and locelized profile I am working on). So t()-ing them in default_profile_final() does not help (there is no language setup and no strings imported at that time). st()-ing them helps *if* you use the installer with a language PO file, since then the type names will be added into the database with their localized name.

Nothing will help that the Drupal locale module (up to at least Drupal 5) is not intended to translate non-literal strings, and it is not advised to be used as such. So if you don't use the installer with a locale file in place (ie. with a translated interface), the current Drupal architecture can't help in translating the node type names. If you import the language strings after Drupal is installed, these type names will stay English, since these are already in the database, and the locale module is not to be used with non-literal stuff.

By the way moving the t()-ed strings in default_profile_final() to be st()-ed would also make them disappear from the runtime string collection, so it will not be expected to be translated anyway.

Am I missing someting here? Fresh checkout of HEAD.

We do not localize the anonymous user name, input format names, taxonomy term names, forum vocabulary name, etc. All user-editable content must be localized by hand. This is how it has always been in Drupal. i18n allows you to get around this.

Yes, it is more visible now, but the problem has always existed and hasn't changed at all.

Steven, we are translating most customizable strings shipped by default before being inserted into the database. An example process: you import a locale, go to the user settings form and see the user mails editable in the used locale, because those are not yet saved, so shown translated. After you save them, they are keep being in the language you saved them in, and never translated by Drupal to another language.

This issue become a lot more visible because default node types shipped are not showing this behaviour.

I agree with Steven: this is not locale's task. If you want to ship a Hungarian Drupal, create a drupal-hungarian.profile and update node_type with an SQL. This is user input data which kind is not translated at all.

The issue we need to look at here is this: Why when default_profile_final() is called, are those t()s not pulling the translated strings from the installer's .po file. Is it because we're using t() instead of st()? If so, that is a bug (or just quirky behavior) and we'd need to document/fix it. That would be weird though since even though we have access to a full bootstrap in profilename_profile_final(), we still must use st() as the translation is somehow not truly active yet.

@meba - Can you try switching those t() calls to st() in that function and see if that works for you?

Oops. I mean, we need to figure out why t() isn't pulling the translated strings from the database in default_profile_final() since in theory the installer's .po strings should have been put in the db at that point.

Sorry chx for the cross-post, but I think this is a valid issue. We already have the facility in place in st() to pull the language strings from the selected $install_locale so I think we should be able to translate any default setup right off the bat. I just don't have time to test this ATM, but will a bit later if no one else can.

@meba Then why menu items (see screenshot) are translated? This is not different case.

Indeed, this is a bug. Menu items should not be translated there.

@meba This is NOT true. Anonymous user name is localized immediatelly after you import lang.po. This is the same case. Why anonymous user name (user editable string) is localized and default node type name is not?

Because you did not save the general settings page before you did import your translation. Try saving those settings into the database before importing the translation, and it will not get translated.

@meba - Can you try switching those t() calls to st() in that function and see if that works for you?

Note that it will only work if you have these strings in the single PO file used in install time (the $langname.po you put into the install profile folder).

@chx: I agree with Steven: this is not locale's task. If you want to ship a Hungarian Drupal, create a drupal-hungarian.profile and update node_type with an SQL. This is user input data which kind is not translated at all.

Every data which becomes user input once saved into the database but is a literal string provided by default by Drupal is translateable or at least this is the theory. This includes editable menu item titles, user related emails, etc. This kind of user input is translated "before it becomes user input".

@RobRoy Oops. I mean, we need to figure out why t() isn't pulling the translated strings from the database in default_profile_final() since in theory the installer's .po strings should have been put in the db at that point.

RobRoy, there is no default language added in the installer, and there are no strings imported by Drupal 5 (in the default profile). So the installer strings will definitely not end up in the database, they are read for one time usage into the memory, and then thrown away. There is no need to add the weight of the installer strings to a live site, as these strings are not used on a live site.

This patch tries to fix the st() issue and the node types accidentaly being translated in the menu. Needs testing/review.

OK, grabbed a fresh checkot of HEAD, patched it with my patch, added a hu.po (Hungarian installer.po) with these lines added and done the install. Now I see Boo and BooHoo as the two names of the types on the installed interface, ready to get used.

msgid "Story"
msgstr "Boo"

msgid "Page"
msgstr "BooHoo"

It works for me. I don't think we can do anything better then this for Drupal 5.

Goba, thanks for explanation and patch.

I didnt have time to test the latest patch yet! But what is about the people upgrading from 4.7? In 4.7 these strings were hardcoded in story/page.module and therefore translatable. Will these strings also be converted when the module node types are replaced with cck-like content types? And will the content type names be translated depending on locale? Or will it be one name for all languages?

In 4.7 the translation will be for the term 'page' not 'Page' so I think that is a moot issue; they'll need to update their translations either way.

@profix898: system_update_1005() does the update you are talking about (in modules/system/system.install). That inserts the strings t()-ed, so if a translation of these strings are ready in the database at that point, then these will get translated.

As webchick pointed out, the node types were named page and story (note the all lowercase name), so it is unlikely that people are going to have Page and Story translated in their database. This means, updaters will get the English names for these node types (unless they first import a translation of Drupal 5, or at least the translation of these strings).

@Gábor: Ok, Thanks for explanation. So this shouldnt be a problem in most cases. But it might be a little messy when you have a multi-language site with i18n. In that case you would need to add multiple (almost) identical content types: all with same properties but with different labels, right? Shouldnt be the labels translatable and only the machine-readable name fixed? Otherwise it is very difficult (or even impossible?) to update a multi-lingual site from 4.7. I guess there is no feature to convert a bunch of nodes to a different content type, right? So one would need to create new content types (one for each language) and move existing nodes into nodes of the newly created (language-specific) content types manually ... (In 4.7 all languages were sharing e.g. the 'page' type which labels were translatable).

profix: i18n is another concern completely. Drupal does not support internationalization of content or variables out of the box, thei18n module has to provide this.

I tested the patch with and without a .po file, both english and other locale, and it works fine. Good job.
Committed to HEAD.

See also this http://drupal.org/node/735466 and this http://drupal.org/node/735468 for D6.