[theme-reviewers] Can Text Domain be name of the Theme shop?

[Hugo Saner]

Okay it starts to make a little more sense and I’m not even going to begin to start the topic of how that will all work :)

However that said it has been 6 months since that was written and I presume it is not something that is going to happen any time soon. So it still leaves us with a predicament that you will not approve any of our themes currently as they are and we cannot change them without completely dropping the framework structure that we currently use which would take months to sort out. That means none of our themes will get updated and users will be left frustrated. The only way we can quickly turn this around is to drop translation completely which is also not going to make anyone happy.

Can theme developers like ourselves who have set up on a framework not be given sometime to turn this around seeing as it doesn’t affect anything currently? This would give us some time to work out if we can get something working in a framework that will follow this directive without punishing our users.

Thanks

On 6 Feb 2014, at 13:24, Srikanth Koneru <tskk79 at gmail.com> wrote:

> http://lists.wordpress.org/pipermail/theme-reviewers/2013-July/014378.html
> 
> 
> On Thu, Feb 6, 2014 at 6:43 PM, Hugo Saner <hugo at sanerdesign.com> wrote:
> Seeing as theme frameworks are so popular and the basis for a lot of theme developers work can this future core feature that has yet to be written not bend a little to allow this framework trend to work?
> 
> I just cannot see how we will be able to do any translations for our free themes otherwise
> 
> 
> 
> On 6 Feb 2014, at 12:17, Srikanth Koneru <tskk79 at gmail.com> wrote:
> 
>> Text domain must be the theme slug, not a out dated rule but a rule to facilitate some core feature in future.
>> 
>> 
>> On Thu, Feb 6, 2014 at 4:54 PM, Bryan Hadaway <bhadaway at gmail.com> wrote:
>> I think the rule should simply be that it must be unique to the theme and not generic. A theme shop's name is definitely unique, relevant and appropriate enough to not cause any issues/conflicts and make sense to the end-user.
>> 
>> I see 0% danger in this, perhaps it's more an out-dated rule, with a philosophical reason or it's simply always been the rule so the thought is "Why change it?"
>> 
>> In theme development and management in general where it concerns developers or theme shops who have essentially built their own framework and then release multiple theme designs on top of that one unique framework, I think it's very good practice to keep everything consistent and tight, same slugs, function prefixes, text domains etc etc.
>> 
>> This is not only good for ease of managing the project on the development's side, but also ease-of-use for the end-user who may decide to for example upgrade to the pro version of a theme or try another one of the shop's free themes, keeping everything seamless and options intact.
>> 
>> I can only think of pros as far as development consistency like this is concerned, but would be interested in hearing what some of the cons may be, if any, for keeping the rule intact without a revision.
>> 
>> _______________________________________________
>> 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/20140206/12b41587/attachment.html>