Hi Gábor,

I understand that classifing contexts is no l.d.o's job, but it's certainly something that would need to be done within Drupal Core development. I'm just wondering if there's still a time window for doing that in Drupal 7, and how it could be done. Sure there's also no easy answer on that, but... any suggestions on how to start changing it?

On Sat, Jan 16, 2010 at 12:30 PM, Gábor Hojtsy gabor@hojtsy.hu wrote:

Hi Jose,

It is not up to localize.drupal.org to introduce contexts. Unless actual Drupal modules and themes use contexts, trying to introduce any context from the outside is not possible. The new Drupal 7 localization API changes allow for contexts, so only modules and themes written for Drupal 7 can take advantage of that (and only if they explicitly do so).

BTW adding plain "noun" and "verb" contexts is not generally useful. Think of "view". As a noun it can be at least three different things I can think of right now: "a database view (as in CREATE VIEW ...)", "a view you see through a window, at the top of the mountain, etc", "a views.module created view". These might be translated to three different things even though all three are nouns.

Gábor

On Fri, Jan 15, 2010 at 8:56 PM, José San Martin jz.sanmartin@gmail.com wrote:

...

Hi,

I've just looked at contextualized translation in localize.drupal.org. It's just great, but there is an issue about it...

The only context available is "Long month names".

Shouldn't there be contexts to differentiate word-class (noun/verb) ambiguous words, such as Filter, View, Update?

If there's work to be done on this issue, how could I help?

José San Martin Brazilian Portuguese team _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations

---

translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations

Hi! We need to document which contexts are needed for which strings. Then these contexts can be used for contrib at least, and included in core later.

I propose we start documenting these on a handbook page, for instance divide it in "Implemented" which only contains "May" so far, and "Proposed" which will contain the rest for now.

If a string is used in one context in core, and in another in contrib, we should use the core meaning as default context. Then we will only have a problem for D7 if a string is used in several contexts within core.

2010/1/18 Gerhard Killesreiter gerhard@killesreiter.de:

I am afraid that there is no such time window anymore for core. However, you can still work with contrib authors to improve the situation.

I think I've read somewhere that fixes of typos in the text are still welcome (couldn't find it again when I tried). If there are a few contexts which make a big difference, maybe it's not completely impossible to get them in? After all, the string freeze is there for translators' sake, so if the translation community strongly request a few exceptions to the string freeze, that might be possible.

Hilde