[theme-reviewers] Localized strings and dynamic text domain.

[Chip Bennett]

I am in favor of retaining the requirement that Themes use theme-slug as the
textdomain (which is currently the requirement). It is one of the only ways
of ensuring a completely unique namespace.

Chip

On Thu, Oct 6, 2011 at 10:24 AM, Edward Caissie <edward.caissie at gmail.com>wrote:

> So we put the blame squarely on `gettext` and make it a "REQUIRED" item the
> textdomain must be a hard-coded string, which we have already recommended it
> be the theme-slug. Seems simple enough to me.
>
> The discussion should continue with whether the theme-slug be the best
> practice (required?) string or if another relevant string can be used in its
> place ... personally I would side with the textdomain === theme-slug.
> Reason being, if the code/application in question advances enough then the
> "clever" idea of using a variable/constant might work correctly and the
> theme-slug (or plugin-slug as the case may be) is easy enough to grab from
> existing data.
>
>
> Cais.
>
>
>
> On Thu, Oct 6, 2011 at 8:43 AM, Chip Bennett <chip at chipbennett.net> wrote:
>
>> No problem; I'll draft something up, and add it to the discussion list for
>> the proposed 3.3 guidelines revisions!
>>
>> Chip
>>
>>
>> On Thu, Oct 6, 2011 at 7:41 AM, Dion Hulse (dd32) <wordpress at dd32.id.au>wrote:
>>
>>> Yep! the way that WordPress loads the translations is one set of strings
>>> per text domain, if the text domains don't match up, translated strings
>>> don't get used, use multiple text domains, and causes problems with multiple
>>> translation files..
>>> So when you start to load a automatically generated translation file,
>>> suddenly if the author hasn't followed best practice, it might just not work
>>> at all.
>>>
>>> On 6 October 2011 23:37, Chip Bennett <chip at chipbennett.net> wrote:
>>>
>>>> Absolutely, and I appreciate the clarification. :)
>>>>
>>>> So, is this an accurate summary: POEdit (etc.) won't care what the
>>>> textdomain string is, for a given Theme/Plugin, provided that the string is
>>>> consistent throughout the Theme/Plugin. But, *best practice* is to use an
>>>> *actual string*, in order to play nicely in an environment where several
>>>> textdomains are being declared (such as within WordPress)?
>>>>
>>>> Chip
>>>>
>>>>
>>>> On Thu, Oct 6, 2011 at 7:32 AM, Dion Hulse (dd32) <wordpress at dd32.id.au
>>>> > wrote:
>>>>
>>>>> Always use a string.. Don't use a variable, Don't use a Constant.
>>>>>
>>>>> Gettext applications look at the php files as an onlooker, It can't
>>>>> tell what the contents of $lang is, it can't tell the contents of
>>>>> CONSTANT_MY_LANG, It just knows the first param is a string, and the second
>>>>> is the text domain for it. It's basically the same as running a regex over
>>>>> an unknown string, or scanning through a French document looking for the
>>>>> word which comes after XYZ..
>>>>>
>>>>> When you're generating a .pot file from a single theme/plugin, you can
>>>>> specify the text domain you want the resulting file to use.. when you're
>>>>> automating translations for thousands of items (like WordPress.org will do
>>>>> one day..) then you can't guess.. the authors need to be specific for
>>>>> maximum compatibility!
>>>>>
>>>>> Does that help at all Chip? :)
>>>>>
>>>>>
>>>>> On 6 October 2011 23:23, Chip Bennett <chip at chipbennett.net> wrote:
>>>>>
>>>>>> Thanks for passing this along, Mike!
>>>>>>
>>>>>> There seems to be some discussion/disagreement in the comments and via
>>>>>> Twitter. What's the consensus?
>>>>>>
>>>>>> Chip
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 6, 2011 at 1:24 AM, Michael Fields <michael at mfields.org>wrote:
>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> This just came through my Twitter feed:
>>>>>>>
>>>>>>> http://markjaquith.wordpress.com/2011/10/06/translating-wordpress-plugins-and-themes-dont-get-clever/
>>>>>>>
>>>>>>> Thought it might make a pretty good addition to the requirements.
>>>>>>> It also might be a pretty easy check to work into the Theme Check
>>>>>>> plugin.
>>>>>>>
>>>>>>> I'm guilty of this myself in plugins and think that's it's really
>>>>>>> great to have an explanation of why this is wrong :)
>>>>>>>
>>>>>>> Just wanted to pass it along!
>>>>>>>
>>>>>>> - Mike
>>>>>>> _______________________________________________
>>>>>>> theme-reviewers mailing list
>>>>>>> theme-reviewers at lists.wordpress.org
>>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> theme-reviewers mailing list
>>>>>> theme-reviewers at lists.wordpress.org
>>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> theme-reviewers mailing list
>>>>> theme-reviewers at lists.wordpress.org
>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> theme-reviewers mailing list
>>>> theme-reviewers at lists.wordpress.org
>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>>
>>>>
>>>
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>
>>>
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20111006/7eebedff/attachment.htm>