Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This was already discussed many times (especially in #19425): several strings (both in Drupal Core and in contrib) are simply too short not to be ambiguous in some languages. For example 'View', as in 'a view of the Views module', and 'View' as in the action of viewing something (a node, a user, etc.).
It boils down to this:
- There are really very few cases where this happens. Thus we don't need a full featured context system, that will make lookups expensive.
- Thus, we can simply add the context to those strings manually.
- We need that information to be embedded inside .po files.
I suggest we come up with a convention like that one:
- Strings passed to t() can be prefixed with an optional context. The exact way of doing that has to be discussed, but I suggest the
[<context>]<string>
convention, as it should not collide with existing strings, both in core and contrib. - For English, the context is simply automatically stripped by t().
- For other languages, the full string, including the context is used as the lookup key. No fallback mechanism is implemented.
- The full string is exported to .po files by potx, which thus requires no modification.
Examples:
// Short names in format_date() and such.
t("[short-week]Mon");
t("[short-week]Tue");
t("[short-week]Wed");
// View tab
$items['user/%user/view'] = array(
'title' => '[user-tab]View',
'type' => MENU_DEFAULT_LOCAL_TASK,
'weight' => -10,
);
// etc.
Comment | File | Size | Author |
---|---|---|---|
#120 | 221020_upgrade_path.patch | 792 bytes | andypost |
#118 | 221020_upgrade_path.patch | 1.03 KB | andypost |
#118 | locale_D6vsD7_diff.txt | 1.5 KB | andypost |
#111 | msgctxt-bugs.patch | 1.8 KB | Gábor Hojtsy |
#82 | 334283-translation-context.patch | 56.5 KB | Damien Tournoud |
Comments
Comment #1
Gábor HojtsyFormat date already does something like this in a special one-off way. It might be best to standardize on a placeholder format which is always cleared out.
Comment #2
Gábor HojtsyBTW what format_date() does in Drupal 6 is a one-off !long-month-name placeholder which is replaced with empty string and then trimmed, so that the separating space is properly deleted:
Comment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedThe format_date() special case for the long month name looks like a hack, especially that added trim() :)
As I don't think we would need that inside the string, we could standardize on something like "if the first character is '#' (or any other, I don't care), remove the beginning of the string up to the first space".
Comment #4
Gábor HojtsyThe space was added, so that the month name itself is easily recognized and it not part of the placeholder hack. And the ! placeholder was reused because translators know what it is. We can make up a #long-month-name type of placeholder, which is always replaced with an empty string. I think the hard part will be to get people use common context names for View (as in Views module View) and View (as in View this content).
Comment #5
nedjoYes, this would be a welcome improvement.
I think the square brackets (or some other symbol at beginning and end) are more intuitive than the space for designating where the context placeholder ends.
Comment #6
dami CreditAttribution: dami commentedsubscribe
Comment #7
nedjoComment #8
moshe weitzman CreditAttribution: moshe weitzman commentedThis plagues contrib as well. OG uses some context specific words like 'group'.
Comment #9
Panaromic.webdesign.com CreditAttribution: Panaromic.webdesign.com commentedI can take on this. I propose we will go with opening and ending with square bracket. For example, [user-tab]View to indicate not-to-translate to the translator.
Comment #10
KarenS CreditAttribution: KarenS commentedIt's possible strings could have single brackets in a description, so maybe add the pound sign too to be sure of the intention, like:
[#long-month-name]May
Comment #11
Jose Reyero CreditAttribution: Jose Reyero commentedAnother take on context:
a. We just need context for short strings / single words
b. Doing things with strings is dirty
c. Aim for a more useful meaningful one
Thus we can:
1. Have an optional function which possibly doesn't need variables, like tc(string, context)
2. Have the context being human readable, so translators can use it too
3. Set up specific guidelines, translators will help us with their specific troubles
Example, for spanish we have trouble with English words being both a noun and a verb, so we could use
tc('post', 'Name for content sent')
tc('post', 'Action of sending content')
This way we'll have really useful context
Comment #12
Damien Tournoud CreditAttribution: Damien Tournoud commented@José: on most translation workflow, the context is useless if not directly in the string. Adding context in .po files comments and support for them on l10n_server would require heavy modifications, including in potx.
Plus, all our all translation system is based on the source string being the key.
Adding simple context inside brackets is the way to go for me.
Comment #13
Jose Reyero CreditAttribution: Jose Reyero commented> on most translation workflow, the context is useless if not directly in the string.
The context in the string itself is mostly useless for non technical translators and it is really ugly when reading the code.
I am proposing a *really useful* one that both makes code more readable and can be displayed to translators as meaningful words.
> Plus, all our all translation system is based on the source string being the key
We just need to change that. Actually we are working on adding more options as we need it for user defined string
So I just mean if we are going to go through this, let's make it a) nice b) readable c) useful
Comment #14
Panaromic.webdesign.com CreditAttribution: Panaromic.webdesign.com commentedThis is my line of thinking, let me know what you think:
Comment #15
Panaromic.webdesign.com CreditAttribution: Panaromic.webdesign.com commentedComment #16
Jose Reyero CreditAttribution: Jose Reyero commentedFollowing up with the idea in #11, some more considerations (and one more reason why it is better).
Context is module dependent, so if a hundred contrib modules define the same string with different context (even if the meaning is the same, they can mark the context differently we get to this: ******* We need to handle fallbacks *******
Think of this situation (string, context): the string (post, noun) may be translated for (post, content object) and (post, verb) and as a word without context too.
1. First we search for (post, noun), no luck
2. We search for the word without context, no luck either
3. Then we should be able to search for the same word in any context. If we add the context into the string '[#verb]post', then we cannot do this without some slow 'LIKE' query.
So I think we need to:
- Add a new context colum to locales table
- Use this new tc() function or similar that may fall back to t() if the word is not found for the required context
- About the po extractor we just need to append the context to the location, or replace the location by the context
Comment #17
Panaromic.webdesign.com CreditAttribution: Panaromic.webdesign.com commentedThis is my proposal:
Syntax: t('string',array('#context'=>'xxx'))
Here xxx can be only one of the pre-defined strings, so far we have identified it can be either 'noun' or 'verb'. Any other idiosyncrasies of English language can be captured here as a context with a suitable id. Let us assume the default context is noun, thus a string without context is treated as a noun in further processing steps.
Inside t() function
First, check for error in context id, i.e. noun spelled as nuon can be rejected and error message can be sent at this stage.
Second, append the string with its context, i.e string becomes [#xxx]string
Third, hand over to locale module
Inside locale module
Retrieve the translated string by joining tables locales_target and locales_source (no change is required in the current code)
If it is a new string add to the table, note the context is already part of the string.
As each string with its context appended to it is different than the same string with a different context, they all get assigned different 'lid' key in the table hence, we don't need 'LIKE' in the query either.
Inside potx.inc
While processing string with context, add an additional information next to 'msgid' field pertaining to its context as a help tip for the human translators
plus append [#xxx] inside the msgstr field to avoid any typo errors. A typical entry in .pot will look like
#: source location information
msgid "string" msgcontext "verb"
msgstr "[#verb]"
The translator has to insert the translated string after the context information in msgstr field.
Although my solution is simple in terms of code or table change, but it does hinge on code modification in potx.inc. I don't know how easy or difficult this code change is, waiting for reply from Gabor. You can follow my posting here http://drupal.org/node/369943
Comment #18
Gábor HojtsyThe context would then be supported by functions like format_plural() and friends. Like format_plural($num, '@count view', '@count views') has the same problem of not telling you whether view is a verb or noun. To me it sounds more logical to add a third parameter after the variables and before the language code to specify context and leave it at NULL by default.
Also, thinking should be put into the same things for menu items and such, so a storage mechanism needs to be figured out for menu item titles and other magically translated things as well. Menu item titles can equally be short, like 'View'.
Comment #19
KarenS CreditAttribution: KarenS commentedI would caution against trying to decide ahead of time what the allowed contexts will be. There are many other possible ones besides 'noun' and 'verb' and it will be impossible to identify all of them. In the Date API I'm trying to create context for things like 'a very short (one letter) abbreviation for Monday', 'a short (two letter) abbreviation for Monday', 'the normal (three letter) abbreviation for Monday', 'the abbreviation for May', 'the full month name for May', 'The word Repeats used in a menu tab', 'The word Repeats as a verb in a sentence', 'the word second as in hour/minute/second', 'the word second as in first/second/third'. It would be best if 'context' can be any text the module needs to provide to explain how this word is used.
Comment #20
hass CreditAttribution: hass commentedsubscribe
Comment #21
Jose Reyero CreditAttribution: Jose Reyero commentedAgree with Gabor (#18), context is better as a separate parameter we need all around. However a shorthand function for simple t(), may help writing code faster (and using context more) for short strings (#16)
Also I agree with KarenS (#16), that we cannot predefine contexts beforehand, as each module / usage can have its own very specific needs, so a plain string will be better. We just need a good fallback system so we don't need to have always 10 translations for the same string, just for the languages/words where it makes sense.
So for now maybe we should focus on how the API is going to look, think of simple but flexible 'contexts'. Standardization can come later when we have compiled a big list of context usage, and we have a full list of requests like 'I need to know whether this is a name or a verb' for translating to xxx language.
Comment #22
yhager CreditAttribution: yhager commentedSubscribing
Comment #23
XanoWhat about using tags like DBTNG does?
Comment #24
Freso CreditAttribution: Freso commentedSubscribing. :)
Comment #25
Damien Tournoud CreditAttribution: Damien Tournoud commentedCourtesy of the flight back home from DC... here is a preliminary patch for adding msgctxt support in Drupal. This:
- adds a $context parameter to t(), just before $langcode to limit API changes
- adds a $context parameter to format_plural()
- load msgctxt from .po files
- save msgctxt to .po files
- tweak the string translation UI a little bit
On the TODO:
- should the empty context be saved as NULL in the database?
- upgrade path from D6 to D7 (this is tricky)
- convert all this to DBTNG (apparently not done yet, but outside of the scope of this patch)
Comment #27
hass CreditAttribution: hass commentedGreat that you are working on it. A few findings... only patch code wise...
1. Is this change intended? Looks wrong.
2. I thought this patch adds a context, therefore I think we do not need the below any longer... but I''m not 100% sure.
Comment #28
hass CreditAttribution: hass commentedcrosspost
Comment #29
Damien Tournoud CreditAttribution: Damien Tournoud commentedFixing 2 and 3 from #27. As indicated above, the upgrade path for that is tricky, as it needs to happen before update.php bootstrapped the Drupal 7 code base, in something like we did for D6 (update_d6_requirements()).
Comment #30
Damien Tournoud CreditAttribution: Damien Tournoud commentedOups.
Comment #31
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis one should actually pass.
Comment #32
hass CreditAttribution: hass commentedHow should the "context" be used in generally? I have never worked with contexts...
Comment #33
Damien Tournoud CreditAttribution: Damien Tournoud commented@hass: the use of this has been discussed in this issue. You can also take a look at [1] for a more generic introduction.
[1] http://www.gnu.org/software/gettext/manual/gettext.html#Contexts
Comment #34
hass CreditAttribution: hass commentedYeah, but I thought more about defining rules for developers - how the context need to be named. Naming a context in a way like
pgettext ("Menu|Printer|", "Connect")
sounds very good and individually, but we are not developing GUI software like this and context names like'Long month name'
may potentially collide with other context names.This question have not so much to do with your patch... it's more about the docs we need to write afterwards to tell others - make sure your context depend on module names or something like this... for e.g. "views menu|admin|build|views", "date_popup next" and "date_popup prev" for example. We need to have rules for this naming like code style rules... :-)
Thank you for the link.
Comment #35
hass CreditAttribution: hass commentedAnd we shouldn't forget to explain "why" we need this and "when" it need to be used (for e.g. strings with less then equals to - one/two/three words).
Comment #36
Damien Tournoud CreditAttribution: Damien Tournoud commented@hass: those details will be ironed-out later. The patch only implement how to technically deal with contexts, see the rest of the issue for why this is needed. The context is *always* optional.
Comment #37
chx CreditAttribution: chx commentedI just would like to say that reading the issue filled me with dread but then people turned from the evil of string parsing to arrays. I like Damien's patch a lot.
Comment #38
chx CreditAttribution: chx commentedPlease note that the world is moving en masse to msgctxt support instead of string mangling. http://www.poedit.net/trac/ticket/148 has a good of list of who: KDE, Gnome, Yii framework. poedit apparently keeps the msgctxt intact at least now even if it does not display it yet.
Comment #39
Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commentedI like the general idea a lot.
I am not sure I like the signature of t(). I think that the patch at least has a lot of NULLs in there.
Maybe t($string, $args = array(), $context = array/()) would be better? in $context there would be $context['langcode'] and $context['context'].
The laguage code is after all only a special kind of context.
One could also merge both into the first array.
Comment #40
Damien Tournoud CreditAttribution: Damien Tournoud commented@Gerhard: there are a lot of NULLs in the patch, because we simply don't use the context parameter for now. The idea is that we will probably use much more frequently the $context parameter then the $langcode parameter, hence the suggested order.
Merging language and context into one parameter? why not.
Comment #41
Freso CreditAttribution: Freso commentedIf we're merging language and context into one parameter, why not simply make a "context" index and a "language" index in
$args
? The$langcode
parameter is not about context, it's about what translation to try and fetch - ie., it's saying nothing about the string at hand.Comment #43
Jose Reyero CreditAttribution: Jose Reyero commentedI like a lot the idea of an array parameter for all these, so we can easily extend t().
where $params may contain:
- context
- langcode
- textgroup
etc.....
This will also help with this other patch #361597: CRUD API for locale source and locale target strings
Comment #44
XanoBeware that this will probably be a heavy performance drain (merging with default params) or a PITA for developers (no defaults).
Comment #45
Damien Tournoud CreditAttribution: Damien Tournoud commented@Xano: since when merging default parameter is an "heavy performance drain"?
Comment #46
Xano"will probably" should have been "might". This is because t() is being called dozens if not hundreds of times per page load. Handling default values (and offering the possibility to translate to multiple languages, requiring Drupal to load more than just the current language) for so many calls might decrease Drupal's performance, but we'll need benchmarks to be sure.
Comment #47
Damien Tournoud CreditAttribution: Damien Tournoud commentedI'll reroll that once #353883: Convert locale.inc to dbtng. is in.
Comment #48
Gábor Hojtsy1. I agree that an array based argument format would be better. We are getting too many parameters here. I like the signature from Jose in #43 better then naming the extra array $context. $params sounds better, not misleading.
2. For the tests to truly test what we do here, some PO importing would be in order. Import simple .po files with and without context and see if the expected strings show up in the DB IMHO.
3. The msgctx support I totally agree with. As soon as core supports it, the other tools around it would need to be updated, but that is just natural :)
Comment #49
stella CreditAttribution: stella commentedThe patch in #353883: Convert locale.inc to dbtng. has now been committed, so re-opening.
Comment #50
Damien Tournoud CreditAttribution: Damien Tournoud commentedHere is a reroll, now with an import test! Let's see how it goes.
Comment #51
sunAwesome. Plain awesome. Even comes with tests.
The only thing that prevents me from marking as RTBC is that we want to put comments above the remarked line:
Given this patch, and the need for it in non-English speaking countries, I would like to propose to commit this patch after this (simple) re-roll. Since the testbot seems to be happy, we should take the "core-breaking-phase" serious, and make sure to flesh out any resulting fixes until D7 is released.
This deserves a CHANGELOG.txt entry as well. Great work, Damien!
Comment #52
sunBumping priority.
Comment #53
Freso CreditAttribution: Freso commentedHm. If you take a look at the locale.inc file (or just the patch), you'll see that there are plenty of lines with "end-line" comments, so I'm not sure this is an issue here. If it is, perhaps it would be better to apply this (noting its importance), and then make a new (code style) bug against locale.inc, for the "end-line" comments to be "above line" comments?
Comment #54
Freso CreditAttribution: Freso commentedAnd here's the patch from #50 with CHANGELOG updated.
Comment #55
hass CreditAttribution: hass commentedComment #56
Dries CreditAttribution: Dries commentedExcellent patch. It is almost ready to be committed:
1.
For people that are unfamiliar with msgctxt (i.e. 99% of the people), I think it is worth explaining what the "context" is used for. It would not hurt to extend the examples.
2. There is no upgrade path yet for the database change.
Comment #57
webchicksubscribe, per sun, although it looks like Dries beat me to it. :)
Comment #59
andypostSo here is reroll with upgrade path with db changes.
Suppose possible somewhere in core still hook_mail functions that should be examined as already
contact.module, update.module, and user.module
for
t(..., $langcode)
+ fixed 1 line in user.module
For me is not clear - what this for?
Comment #60
andypostforget to change status
Comment #62
andypostanother try
Comment #64
andypostupdate after #422358: convert common.inc to use new static caching API
Comment #65
andypostOne more fix - update trying to create cache_path with t() in description
There's a still broken update process
Comment #66
andypostNow upgrade fixed!!!
1) Field context added in
update_fix_d7_requirements()
2)
locale_update_7000()
updates only primary keyComment #67
Damien Tournoud CreditAttribution: Damien Tournoud commentedThanks andy. This is ready to go in.
I don't exclude we might have missed some t() calls. Probably not much, but it is completely possible. We will fix those later on if we find them. The test bot is happy, which is already a good sign.
Comment #68
andypostOps, not null should be TRUE, added check in update_7000 for existence of field
Comment #69
andypostlocale_update_7000()
is useless because no support to HEAD updatesso all moved to
update_fix_d7_requirements()
Comment #70
Damien Tournoud CreditAttribution: Damien Tournoud commentedIt is messy to put the upgrade path for one part in update_fix_d7_requirements() and for other part in locale_update_*() function. I suggest we simply catch the PDO exception in locale() and return the English version of the string in that case. This way we can move all the upgrade path in locale_update_7000() where it belongs.
That will make the updated effectively fallback to English until we have created the missing column. It doesn't matter a lot: because the new translations are not already loaded, the updated process will be mostly in English anyway.
Comment #71
andypost@Damien Tournoud catching of exceptions in this situation brings nothing except performance loss!!!
Because it breaks all logic with locale()
I strongly disagreed with changing locale() on this manner (exceptions should be visible)
Patch from #69 works but with removing locale_update_7000() current installs have to visit update.php
Comment #72
andypostI cant make a good documentation of functions so need help with it
Comment #73
andypostReroll for current HEAD
Because get_t() cannot be changed after full bootstrap we need add new field before migration process in update_fix_d7_requirements()
Also we need to change primary key for locale_source table:
next two patches
1) t-context-noupN.patch primary key updated inside update_fix_d7_requirements() so no hook_update_N
2) t-context-up7.patch with this function listed bellow
Suppose first much better then ugly update_N
Comment #74
catchThe index update should be in locale_update_7000()
Documention for update_fix_VERSION_requirements() says that you shouldn't do anything destructive in there which would prevent dropping back to D6 - since just visiting update.php at all is going to change the state of your database. IMO adding and dropping an index comes under this.
Comment #75
andypostReroll tracking changes in HEAD
As proposed by catch
+ index changes moved into locale_update_7000()
+ field addition is in update_fix_7_requirements()
Comment #77
webchickHEAD was broke.
Comment #79
andypostreroll
Comment #80
Dries CreditAttribution: Dries commentedGiven that DamZ kicks this off, I'd really like him to review this patch.
Comment #81
Damien Tournoud CreditAttribution: Damien Tournoud commentedOne little piece was missing: we need to add context to the string overrides example in default.settings.php... The only issue is that I have no idea how to explain how this works:
How to explain the
''
magic?Comment #82
Damien Tournoud CreditAttribution: Damien Tournoud commentedAn updated patch with the change to default.settings.php.
Comment #83
andypostYes, this change was lost
As for me it works fine (tested upgrade d6-d7 on mysql)
Comment #84
andypostsuppose it should be commited then needs update docs
Comment #85
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks!
Comment #86
Dries CreditAttribution: Dries commentedMarking 'needs work' until documentation was updated.
Comment #87
webchicktagging.
Comment #88
Gábor HojtsyThree notes on this:
- Drupal.t() and Drupal.formatPlural() was not updated to support contexts; it is very likely that people would like to print "May" in Javascript too with proper contexts; also we tried to do our best so far to match up the JS translation API to the PHP one
- While the tests use the "Short month name" and "Long month name" context, the actual common.inc code only uses the "Long month name" context, and uses empty context for the short one. This might be confusing. We need to have some guidelines on context usage. Should the "default" translation have empty context and others marked with their respective contexts (like on common.inc) or should they all have contexts (like in the tests).
- It would probably make sense to add a context-less item to the test .po file and test that too.
Sorry that I did not have time to review the actual patch in more detail earlier.
Comment #89
Damien Tournoud CreditAttribution: Damien Tournoud commented@Gabor: I suggest we open separate issues for the javascript translation. Defining guidelines for context is also a separate issue.
Comment #90
Gábor Hojtsy@Damien: even if defining guidelines is a separate issue, we should probably not use two different approaches in the testing code and the live code. Created #488496: Implement missing msgctx context in JS translation for feature parity with t() for the missing implementation of JS support for contexts.
Also, documented this change at http://drupal.org/node/224333#locale_context with:
Please review and correct as needed. (Also not sure we have a place to document settings.php changes and changes for translators).
Keeping on needs work for fixing the test!
Comment #91
Damien Tournoud CreditAttribution: Damien Tournoud commentedTagging as novice to fix the tests, and lowering the priority.
Comment #92
hass CreditAttribution: hass commentedI'm not sure why we use
!long-month-name
in the D7 examples if this is the currently used hack/workaround for missing context support. I would suggest that we recommend NOT to uset('May');
at all as this will cause context sensitive issues... I'm not sure if we should recommend to use contexts for all single/two word strings.Comment #93
Summit CreditAttribution: Summit commentedHi, Would this also be possible to use in D6, adding the msgctxttype, and langcode. I would like to get to the english locale stored equivalent msg-string through the dutch stored msg-string, while using dutch as default language in locale.
I am sorry if this is not the appropreate place to ask.
EDIT: it seems looking at http://drupal.org/node/82499 t($string, $vars, $langcode) could work..
Sorry to disturb you if this is the case.
Martijn
Comment #94
macgirvin CreditAttribution: macgirvin commenteda bit late but subscribe
Comment #95
hass CreditAttribution: hass commented@Garbor: I suggest to change the D7 examples to the below for better understanding. I have introduced February with a real short and long version for better understanding and removed the D6 hack completely:
Comment #97
Gábor Hojtsyhass: As I explained above, 'Short month name' is a context mistakenly used in the .test, while it is not actually used by Drupal core. This issue is marked "needs work" to either fix the test or fix the lookup of short month names, because they are inconsistent. Otherwise you noticed perfectly, that there was a copy-paste error, !long-month-name is not in D7 :) So I've fixed that to:
Otherwise we need resolution on the contexts used for month names in test/core wise.
Comment #98
hass CreditAttribution: hass commentedMaybe I do not understand contexts, too - but only because of the short version is not yet used in core - why shouldn't we use or explain it? Please see my above examples. I think they should better be added to the examples.
The short version of "May" is a very bad example/idea... we have seen many more difficulties in the date module as in core. I cannot remember all, but a few are "Second" what could be a "time range" or "2." or "the second of something" (difficult to explain if something have the same word in English) or "min" for "minute" and as abbreviation of "minimum". Therefore I would never ever use single words without contexts if I cannot be 100% sure this is a unique word like "February" (however I cannot say myself if there are different meanings in other languages for this word). I'm pretty sure all 3-letter-words could easily become context sensitive issues.
Bad and could cause context sensitive issues:
Good and much saver about context sensitive issues:
Comment #99
Gábor Hojtsyhass: Adding the "Short month name" context to the example does not make it work. Core does not look up the short "May" with that context.
Comment #100
hass CreditAttribution: hass commentedYes, if not used in core, but if myModule use makes use of "Short month name" as context - it is looked up if the string is shown in myModule.
Comment #101
Gábor HojtsyWell, we are providing core examples in this upgrade guide, so if let's stick to how that works. I agree that 'May' standalone might be misleading and that adding the explicit "Short month name" context could be useful.
Comment #102
andypostSuppose we forget about short month names
So I think better to make "Date" strings in context or provide special handling of "Short month name" as already for "F"
Comment #103
hass CreditAttribution: hass commentedThere is a need to add a context to
none
strings. Today all this "none" and "None" strings are not translated properly (context sensitive) in German.Comment #104
Damien Tournoud CreditAttribution: Damien Tournoud commented@hass: that's what contexts are for, please open a separate issue!
Comment #105
Gábor HojtsyI'm in the middle of implementing parsing for contexts in potx module, so that actual translators can provide proper translations. Some interesting tidbits I found:
- menu hook strings (tab titles, descriptions) cannot support contexts, however, ambiguous tab titles such as "Track" can easily show up; only if custom title callback is used
- region names and any other .info strings are in the same situation; given that .info strings are mostly unique module names and descriptions, this should not be much of an issue
- as said above, there is no JS level support yet for contexts
This is it.
Comment #106
Gábor HojtsyAlso, since st() and friends did not support anything beyond replacement variables, context support is not on install time strings either. Complicates the maze of functions quite a bit frankly.
Comment #107
Damien Tournoud CreditAttribution: Damien Tournoud commentedI would argue that tab titles, tab descriptions, region names, module names, etc. should all have their how context. Context cannot solve the confusion if two tabs are already confusing in English (for example "View" as a verb or as a noun).
Comment #108
Gábor Hojtsy@Damien did you mean tabs should have their *own* context? That separates them from the rest of the strings, which would generally be bad and would not solve that there can be a tab View which is a noun and another one which is a verb. Context is exactly supposed to solve this problem, and it does solve it with a title callback, so an answer might be that people need to use a title callback in such a case.
Comment #109
Damien Tournoud CreditAttribution: Damien Tournoud commented@Gabor: Yes, I mean that tab should have their own "Menu tab" context. As I said above: "contexts cannot solve the confusion if two tabs are already confusing in English (for example having two tabs labeled "View" as a verb or as a noun)."
Comment #110
Gábor Hojtsy@Damien: I think having contexts for where it is used is not a good idea. Contexts should be used to resolve translation conflicts. A "menu tab" context will not solve this problem, it would segregate menu items and make it harder to reuse translations for menu items which are otherwise the same in page titles, etc.
@all: I've implemented initial support for contexts in the D7 branch of the template extractor (potx) module, so translators could actually extract string with context. My implementation diff is on the comment at http://drupal.org/node/369943#comment-1819430 so you can glance over that and see places where I used POTX_CONTEXT_NONE to denote things which don't support context (but there are things not marked with this one even). Things like $t, st, Drupal.t, Drupal.formatPlural, watchdog(), hook_menu() etc translate strings but are context-less. I'll go on to backport these changes to the D6 version of potx and adding context support to l10n_server so that translators can start translating D7 stuff when the time comes with context supported.
Comment #111
Gábor HojtsyHere is the test fixes and one follow up bugfix attached.
1. As discussed above, Drupal core does not use the "Short month name" context, so it should not test for it either. That is easily misleading.
2. Also, the import code in locale.inc was missing a $. Found out while working on import support for l10n_server and ported code from this patch to that Drupal 6 module at #524112: Support for working with Drupal 7 context data.
Comment #112
Dries CreditAttribution: Dries commentedI committed the bug fix. We can continue to discuss the other issues. :)
Comment #114
Sutharsan CreditAttribution: Sutharsan commentedThe Views example Damian uses in #107 can be solved by using a linguistic context instead of a web or drupal context. "Verb" and "Noun" should be contexts to translate "View" correctly.
Comment #115
Gábor Hojtsy@Sutharsan: well, view as a noun can still mean multiple stuff :) "view" as in "what a nice view you have here in Paris" or "I've just set up this database view in PostgreSQL" or "SimpleViews module just makes setting up a basic view much easier". When appearing in a module, a webcam module might have "view" as a noun in the above sense (a bit contrived I admit), a database management module could have the database view thing and Views surely has the Views view thing.
Comment #116
sunI think this issue is fixed and we should move to (at least one) separate issue to discuss potential contexts, no?
Let's discuss that stuff in a separate issue. Please add a link here. (I'd create one if I'd know all details of this thread to post a sane summary as starting point.)
Comment #118
andypostUpgrade path is broken http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/locale/locale.inst...
See attached diff within locale_schema(), but we still have no db_add_foreign_key()
Patch trying to fix this and reorder update functions
If issue #221020: locales_source.location is just varchar(255) and it is not truncated changed for D6 then 7001 should go to 6-extra section
Comment #120
andypostReroll
Comment #121
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #122
andypostTagged
Comment #123
Gábor HojtsyIf the last msgstr value in the .po file is empty, the .po file is considered broken because of the changes in the patch. Follow up bug report opened at #611786: .po file should not be considered broken if last msgstr is empty.
Comment #125
moshe weitzman CreditAttribution: moshe weitzman commentedDoc issue for default.settings.php opened at #635104: default.settings.php should document how to override strings with context
Comment #126
Gábor HojtsyAdding tag.
Comment #127
hedac CreditAttribution: hedac commentedsubscribing.. interested also in drupal 6 version for this