New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow internationalization of Twinkle #129

Open
Huji opened this Issue Oct 6, 2012 · 48 comments

Comments

Projects
None yet
7 participants
@Huji
Contributor

Huji commented Oct 6, 2012

I would like to suggest Twinkle to be internationalized. This will allow easier translation and updating of Twinle on non-English projects.

All we need at this point, is to store the messages in a separate file (or even in the same file, but in a separate array).

@Hello71

This comment has been minimized.

Show comment
Hide comment
@Hello71

Hello71 Nov 9, 2012

I think the concern is not being able to know which strings in which files to change.

Hello71 commented Nov 9, 2012

I think the concern is not being able to know which strings in which files to change.

@QEDK

This comment has been minimized.

Show comment
Hide comment
@QEDK

QEDK Nov 9, 2012

Contributor

Hello71 (Alex) as you said:

I think the concern is not being able to know which strings in which files to change.

No, it will really take a heck lot of a time. (And nobody's even starting up the idea)

Contributor

QEDK commented Nov 9, 2012

Hello71 (Alex) as you said:

I think the concern is not being able to know which strings in which files to change.

No, it will really take a heck lot of a time. (And nobody's even starting up the idea)

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Dec 17, 2012

Contributor

I forked Twinkle ino https://github.com/Huji/twinkle an then tried to load it using https://test.wikipedia.org/wiki/User:Huji/common.js which didn't work. If you help me set it up, I might be able to spend some time working on i18n myself.

Contributor

Huji commented Dec 17, 2012

I forked Twinkle ino https://github.com/Huji/twinkle an then tried to load it using https://test.wikipedia.org/wiki/User:Huji/common.js which didn't work. If you help me set it up, I might be able to spend some time working on i18n myself.

@QEDK

This comment has been minimized.

Show comment
Hide comment
@QEDK

QEDK Dec 17, 2012

Contributor

Did you follow README.md

On Mon, Dec 17, 2012 at 10:01 PM, Huji Lee notifications@github.com wrote:

I forked Twinkle ino https://github.com/Huji/twinkle an then tried to
load it using https://test.wikipedia.org/wiki/User:Huji/common.js which
didn't work. If you help me set it up, I might be able to spend some time
working on i18n myself.


Reply to this email directly or view it on GitHubhttps://github.com//issues/129#issuecomment-11448580.

Contributor

QEDK commented Dec 17, 2012

Did you follow README.md

On Mon, Dec 17, 2012 at 10:01 PM, Huji Lee notifications@github.com wrote:

I forked Twinkle ino https://github.com/Huji/twinkle an then tried to
load it using https://test.wikipedia.org/wiki/User:Huji/common.js which
didn't work. If you help me set it up, I might be able to spend some time
working on i18n myself.


Reply to this email directly or view it on GitHubhttps://github.com//issues/129#issuecomment-11448580.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Dec 22, 2012

Contributor

I will. By the way, is it a good idea that I'm forking twinkle? Or should I branch instead of fork?

Contributor

Huji commented Dec 22, 2012

I will. By the way, is it a good idea that I'm forking twinkle? Or should I branch instead of fork?

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Dec 23, 2012

Collaborator

It's fine to fork Twinkle. If you have code to contribute back to this main repo, you may do so via a pull request.

The best way to load Twinkle is to use this code in your skin JS:

$(function(){
  mw.loader.using( ['mediawiki.util','jquery.ui.dialog','jquery.tipsy'], function(){
        mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-morebits.js&action=raw&ctype=text/javascript');
        mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-morebits.css&action=raw&ctype=text/css', 'text/css');
        mw.loader.load('//en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/twinkle-alpha.js&action=raw&ctype=text/javascript');
  });
});

obviously replacing the URLs with correct ones. If you don't intend on modifying morebits.css and/or morebits.js, you can just keep the default enwiki URLs.

Please say if this doesn't work.

Collaborator

atlight commented Dec 23, 2012

It's fine to fork Twinkle. If you have code to contribute back to this main repo, you may do so via a pull request.

The best way to load Twinkle is to use this code in your skin JS:

$(function(){
  mw.loader.using( ['mediawiki.util','jquery.ui.dialog','jquery.tipsy'], function(){
        mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-morebits.js&action=raw&ctype=text/javascript');
        mw.loader.load('//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-morebits.css&action=raw&ctype=text/css', 'text/css');
        mw.loader.load('//en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/twinkle-alpha.js&action=raw&ctype=text/javascript');
  });
});

obviously replacing the URLs with correct ones. If you don't intend on modifying morebits.css and/or morebits.js, you can just keep the default enwiki URLs.

Please say if this doesn't work.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Dec 23, 2012

Contributor

I will work on it. I assume that twinkle-alpha.js that you load above is the result of running the awk code mentioned in the README, right?

I am also a little confused how the sync.pl code works; I'm not good with perl. What I intend to do is to create a new module for l10n and i18n, and then make all the other modules use it whenever appropriate. I'm not sure if the sync.pl allows for adding a new module. Maybe I should add the new module manually. I am assuming that once the new module is added, any change I make to the JS on wiki can be imported back into the module using the sync code, without changing the sync code itself. Please advise.

Contributor

Huji commented Dec 23, 2012

I will work on it. I assume that twinkle-alpha.js that you load above is the result of running the awk code mentioned in the README, right?

I am also a little confused how the sync.pl code works; I'm not good with perl. What I intend to do is to create a new module for l10n and i18n, and then make all the other modules use it whenever appropriate. I'm not sure if the sync.pl allows for adding a new module. Maybe I should add the new module manually. I am assuming that once the new module is added, any change I make to the JS on wiki can be imported back into the module using the sync code, without changing the sync code itself. Please advise.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Dec 23, 2012

Collaborator

Yes to the awk code. It generates a file which you can copy-and-paste on-wiki. That's the way I've always done it.

I've never used the sync module (I'm not an admin on enwiki so can't update the gadget). It seems to have an option to pull changes from the wiki, so play with it (or read the code) and see what it does. You'll obviously have to change the URLs.

Collaborator

atlight commented Dec 23, 2012

Yes to the awk code. It generates a file which you can copy-and-paste on-wiki. That's the way I've always done it.

I've never used the sync module (I'm not an admin on enwiki so can't update the gadget). It seems to have an option to pull changes from the wiki, so play with it (or read the code) and see what it does. You'll obviously have to change the URLs.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Dec 23, 2012

Collaborator

Please, if you find the documentation in README.md wrong, tell me and I can fix it.

Collaborator

atlight commented Dec 23, 2012

Please, if you find the documentation in README.md wrong, tell me and I can fix it.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Dec 23, 2012

Contributor

I decided not to use the sync script. First of all, I can't install MediaWiki::Bot for some reason. Secondly, my changes are probably not going to be handled by it (because I am introducing a new module).

I will keep you posted.

Contributor

Huji commented Dec 23, 2012

I decided not to use the sync script. First of all, I can't install MediaWiki::Bot for some reason. Secondly, my changes are probably not going to be handled by it (because I am introducing a new module).

I will keep you posted.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Dec 23, 2012

Contributor

Alright. Please take a look at https://test.wikipedia.org/wiki/User:Huji/alltwinkle.js (compare it to the very first revision to see what has been changed/added).

This introduces an i18n object, with the bare minimum functions and properties. Of course, there is still a lot to do, but I would rather clear some things before I continue:

  1. The i18n module needs to be defined even before the defaultconfig because some of the properties of defaultconfig (such as summaryAd, etc) need to be internationalized. Right now, I have placed the i18n code somewhere in the middle of twinkle.header.js but given the i18n needs, I believe it makes sense to move lines 33+ out of twinkle.header.js and into a separate module that is loaded after i18n. If you have a better idea, please advise.

  2. There are two ways to approach the i18n problem:

2.1) We only create and maintain the Twinkle.i18n.messages object for English language; users from other languages will modify it based on their needs. This is how projects like WordPress work; they only add support for i18n.

2.2) We also include the other languages in Twinkle.i18n.messages and maintain them on the git repository. This is how projects like MediaWiki work; they add support for i18n and also maintain translations.

While the second method is pretty easy to achieve (we can easily use TranslateWiki for that), it makes the JS size even larger (imagine 20 languages have translations, and every user has a copy of every language's translations).

I find it beyond me to decide which one is in the bets interest of Twinkle. I'll do 2.1 in my fork, but you can expand it to 2.2 if you like.

Contributor

Huji commented Dec 23, 2012

Alright. Please take a look at https://test.wikipedia.org/wiki/User:Huji/alltwinkle.js (compare it to the very first revision to see what has been changed/added).

This introduces an i18n object, with the bare minimum functions and properties. Of course, there is still a lot to do, but I would rather clear some things before I continue:

  1. The i18n module needs to be defined even before the defaultconfig because some of the properties of defaultconfig (such as summaryAd, etc) need to be internationalized. Right now, I have placed the i18n code somewhere in the middle of twinkle.header.js but given the i18n needs, I believe it makes sense to move lines 33+ out of twinkle.header.js and into a separate module that is loaded after i18n. If you have a better idea, please advise.

  2. There are two ways to approach the i18n problem:

2.1) We only create and maintain the Twinkle.i18n.messages object for English language; users from other languages will modify it based on their needs. This is how projects like WordPress work; they only add support for i18n.

2.2) We also include the other languages in Twinkle.i18n.messages and maintain them on the git repository. This is how projects like MediaWiki work; they add support for i18n and also maintain translations.

While the second method is pretty easy to achieve (we can easily use TranslateWiki for that), it makes the JS size even larger (imagine 20 languages have translations, and every user has a copy of every language's translations).

I find it beyond me to decide which one is in the bets interest of Twinkle. I'll do 2.1 in my fork, but you can expand it to 2.2 if you like.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Dec 24, 2012

Collaborator

The great problem with internationalisation is that Twinkle requires large parts of the code to be changed between wikis. Some modules (diff, fluff, unlink) are cross-wiki portable almost verbatim. Some others, such as CSD, need some code changed to fit local criteria (not just string changes). Yet others, like ARV and PROD, may not even be relevant on other wikis.

Siddhartha Ghai has a project "TWG", a substantial rewrite of Twinkle to solve these and other portability-related issues. However I don't think he has been working on it lately. You should really consider talking to him on-wiki.

Collaborator

atlight commented Dec 24, 2012

The great problem with internationalisation is that Twinkle requires large parts of the code to be changed between wikis. Some modules (diff, fluff, unlink) are cross-wiki portable almost verbatim. Some others, such as CSD, need some code changed to fit local criteria (not just string changes). Yet others, like ARV and PROD, may not even be relevant on other wikis.

Siddhartha Ghai has a project "TWG", a substantial rewrite of Twinkle to solve these and other portability-related issues. However I don't think he has been working on it lately. You should really consider talking to him on-wiki.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Dec 24, 2012

Contributor

True. But keeping things as modular as possible makes it easier for others to modify Twinkle.

Right now, other wikis are using Twinkle despite these limitations. Separating i18n, doesn't solve the problems you just mentioned, and it wasn't my idea to fix those problems either. Separating i18n makes it easier for others to use Twinkle, compared to how they do it right now.

At the current time, people have to scan through the whole code and find all English terms that need translation. This is because translatable messages are not stored together. In contrast, modules (like ARV and PROD) are stored in separate places so disabling them is pretty easy. Even modifying the CSD list is easy because the object defining the CSD items is all in one place. The only part that is all over the place is i18n. That is why I wanted to separate i18n.

Contributor

Huji commented Dec 24, 2012

True. But keeping things as modular as possible makes it easier for others to modify Twinkle.

Right now, other wikis are using Twinkle despite these limitations. Separating i18n, doesn't solve the problems you just mentioned, and it wasn't my idea to fix those problems either. Separating i18n makes it easier for others to use Twinkle, compared to how they do it right now.

At the current time, people have to scan through the whole code and find all English terms that need translation. This is because translatable messages are not stored together. In contrast, modules (like ARV and PROD) are stored in separate places so disabling them is pretty easy. Even modifying the CSD list is easy because the object defining the CSD items is all in one place. The only part that is all over the place is i18n. That is why I wanted to separate i18n.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Dec 24, 2012

Contributor

I just took a look at https://en.wikipedia.org/wiki/User:Siddhartha_Ghai/TWG-i18n.js and it has done a lot of things I wanted to do. I'll ask Siddhartha to take a look at this bug.

Contributor

Huji commented Dec 24, 2012

I just took a look at https://en.wikipedia.org/wiki/User:Siddhartha_Ghai/TWG-i18n.js and it has done a lot of things I wanted to do. I'll ask Siddhartha to take a look at this bug.

@Siddhartha-Ghai

This comment has been minimized.

Show comment
Hide comment
@Siddhartha-Ghai

Siddhartha-Ghai Dec 24, 2012

I started work on TWG to tackle this very problem. My intent with TWG was to have an i18n-able twinkle with the creation of basic modules possible by simply adding messages to an i18n file. The original plan also included making these files editable with a twinkle preferences like interface. This was intended to help solve both translation and portability problems (allowing making slight changes in the basic modules without having to go through js).

The first part (seperating the i18n messages) was completed for some modules in TWG (I've somewhat tested tag and CSD, but other simple modules should work too). I haven't gotten round to implementing a UI for editing the twinkle messages.

Feel free to see the code at http://en.wikipedia.org/wiki/User:Siddhartha_Ghai/TWG.js and the messages at http://en.wikipedia.org/wiki/User:Siddhartha_Ghai/TWG-i18n.js

We can make a github repo out of it if anyone is interested in working on it. I just fixed it so that it provides the basic stuff. Feel free to try it out.

We should note though, that Gadgets 2.0 http://www.mediawiki.org/wiki/Gadgets_2.0 https://bugzilla.wikimedia.org/show_bug.cgi?id=29272 will bring a lot of features with it and doing a lot of work to make twinkle i18n-able without it will probably be duplication of effort. Also note though, that it seems Gadgets 2.0 is unlikely to arrive before June 2013 at least.

Siddhartha-Ghai commented Dec 24, 2012

I started work on TWG to tackle this very problem. My intent with TWG was to have an i18n-able twinkle with the creation of basic modules possible by simply adding messages to an i18n file. The original plan also included making these files editable with a twinkle preferences like interface. This was intended to help solve both translation and portability problems (allowing making slight changes in the basic modules without having to go through js).

The first part (seperating the i18n messages) was completed for some modules in TWG (I've somewhat tested tag and CSD, but other simple modules should work too). I haven't gotten round to implementing a UI for editing the twinkle messages.

Feel free to see the code at http://en.wikipedia.org/wiki/User:Siddhartha_Ghai/TWG.js and the messages at http://en.wikipedia.org/wiki/User:Siddhartha_Ghai/TWG-i18n.js

We can make a github repo out of it if anyone is interested in working on it. I just fixed it so that it provides the basic stuff. Feel free to try it out.

We should note though, that Gadgets 2.0 http://www.mediawiki.org/wiki/Gadgets_2.0 https://bugzilla.wikimedia.org/show_bug.cgi?id=29272 will bring a lot of features with it and doing a lot of work to make twinkle i18n-able without it will probably be duplication of effort. Also note though, that it seems Gadgets 2.0 is unlikely to arrive before June 2013 at least.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Dec 24, 2012

Collaborator

I am very keen for Gadgets 2.0, not least because it will mean you won't have to be a sysop to edit gadget code! But it keeps getting put off. I agree with Siddhartha; the improvements it will bring are probably worth waiting for.

Collaborator

atlight commented Dec 24, 2012

I am very keen for Gadgets 2.0, not least because it will mean you won't have to be a sysop to edit gadget code! But it keeps getting put off. I agree with Siddhartha; the improvements it will bring are probably worth waiting for.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Jul 14, 2015

Contributor

More than 2.5 years have passed and this issue is still unresolved. Moreover, Twinkle has been modularized since then, and Gadgets 2.0 has not been released on Wikipedia. I think it is time to get serious with this.

I would like to take this bug myself. Here is what I plan to do:

  1. Add a new module to Twinkle, called twinklelang.js in which I will create an object that contains the messages for each language, as well as a set of methods for that object that can retrieve the messages (or fallback to English when no translation is found).
  2. Replace all hardcoded messages throughout Twinkle with references to the messages defined in twinklelang.js (although for the time being, I will NOT make console log messages internationalized; only content that is shown in the browser window (messages, link texts, etc) will be internationalized.

Specific suggestions about the above are welcome. If someone assigns this issue to me that would be great too (although you don't have to).

Contributor

Huji commented Jul 14, 2015

More than 2.5 years have passed and this issue is still unresolved. Moreover, Twinkle has been modularized since then, and Gadgets 2.0 has not been released on Wikipedia. I think it is time to get serious with this.

I would like to take this bug myself. Here is what I plan to do:

  1. Add a new module to Twinkle, called twinklelang.js in which I will create an object that contains the messages for each language, as well as a set of methods for that object that can retrieve the messages (or fallback to English when no translation is found).
  2. Replace all hardcoded messages throughout Twinkle with references to the messages defined in twinklelang.js (although for the time being, I will NOT make console log messages internationalized; only content that is shown in the browser window (messages, link texts, etc) will be internationalized.

Specific suggestions about the above are welcome. If someone assigns this issue to me that would be great too (although you don't have to).

@mc10

This comment has been minimized.

Show comment
Hide comment
@mc10

mc10 Jul 15, 2015

Collaborator

If you're willing to take this on, then definitely props to you, but be warned that this will require quite a bit of effort. Style-wise I'm okay with a WordPress-style __() (double underscore) function to wrap around all interface strings, and let that function determine which string to display.

Collaborator

mc10 commented Jul 15, 2015

If you're willing to take this on, then definitely props to you, but be warned that this will require quite a bit of effort. Style-wise I'm okay with a WordPress-style __() (double underscore) function to wrap around all interface strings, and let that function determine which string to display.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Jul 15, 2015

Collaborator

Okay, a couple of suggestions:

  • Start with a simple module first (e.g. friendlyshared) and show your work.
  • One of the real challenges is that, to localise Twinkle, it is not only the message strings that need to be translated. The actual templates and options themselves (for example, the welcome templates, shared IP templates, list of CSD criteria, etc), with their attendant subgroups, parameters, etc. need to be localised. That is why this work hasn't been completed yet - it is a truly enormous undertaking that essentially amounts to "rewriting Twinkle".

If you are going to do this, I would suggest you have a look at the prior attempts at this: Siddhartha Ghai's "TWG" or "TW Global" (probably stored on enwiki somewhere, you may have to hunt for this one) and my initial work on this (now in the branch "twinklelocal" of this repository). It's a big challenge and it will be interesting to see your approach.

If you do end up "rewriting Twinkle", it would be nice to take the opportunity to ditch XML and switch to JSON :)

Collaborator

atlight commented Jul 15, 2015

Okay, a couple of suggestions:

  • Start with a simple module first (e.g. friendlyshared) and show your work.
  • One of the real challenges is that, to localise Twinkle, it is not only the message strings that need to be translated. The actual templates and options themselves (for example, the welcome templates, shared IP templates, list of CSD criteria, etc), with their attendant subgroups, parameters, etc. need to be localised. That is why this work hasn't been completed yet - it is a truly enormous undertaking that essentially amounts to "rewriting Twinkle".

If you are going to do this, I would suggest you have a look at the prior attempts at this: Siddhartha Ghai's "TWG" or "TW Global" (probably stored on enwiki somewhere, you may have to hunt for this one) and my initial work on this (now in the branch "twinklelocal" of this repository). It's a big challenge and it will be interesting to see your approach.

If you do end up "rewriting Twinkle", it would be nice to take the opportunity to ditch XML and switch to JSON :)

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Jul 15, 2015

Contributor

Thanks for both comments!

@mc10 I am aware of how much work it is going to be; that is the primary reason I hesitate to get to this for over two years. I have some free time at hand now, so might as well get this done!

@atlight That is exactly how I wanted to approach this: by starting from a small module and validation my approach with you and others who have more experience with Twinkle. I have seen TWG and I am thinking of a similar approach, except I was thinking of using either JSON or just plain JS objects. Something like:

Twinkle.lang = {
  Twinkle.lang.parse = function(msgid, params = false) {
      // params can be a string or an array of strings, and is used to parse the message
      ....
  }

  Twinkle.lang.messages = {
    en: {
      msg-portlet-name : 'TW',
      msg-confirm-delete : 'Are you sure you want to delete $1?'
      ....
    },
    de: {
      ...
     }
  }
};

And then you would call it like:

/* Example from Twinkle.js */
...
Twinkle.defaultConfig.twinkle.portletName = Twinkle.lang.parse('msg-portlet-name');
somethingElse = Twinkle.lang.parse('msg-confirm-delete', pageName);
Contributor

Huji commented Jul 15, 2015

Thanks for both comments!

@mc10 I am aware of how much work it is going to be; that is the primary reason I hesitate to get to this for over two years. I have some free time at hand now, so might as well get this done!

@atlight That is exactly how I wanted to approach this: by starting from a small module and validation my approach with you and others who have more experience with Twinkle. I have seen TWG and I am thinking of a similar approach, except I was thinking of using either JSON or just plain JS objects. Something like:

Twinkle.lang = {
  Twinkle.lang.parse = function(msgid, params = false) {
      // params can be a string or an array of strings, and is used to parse the message
      ....
  }

  Twinkle.lang.messages = {
    en: {
      msg-portlet-name : 'TW',
      msg-confirm-delete : 'Are you sure you want to delete $1?'
      ....
    },
    de: {
      ...
     }
  }
};

And then you would call it like:

/* Example from Twinkle.js */
...
Twinkle.defaultConfig.twinkle.portletName = Twinkle.lang.parse('msg-portlet-name');
somethingElse = Twinkle.lang.parse('msg-confirm-delete', pageName);
@mc10

This comment has been minimized.

Show comment
Hide comment
@mc10

mc10 Jul 15, 2015

Collaborator

Twinkle.lang.parse is probably too long—you don't want to clutter up the code. In this case I think a short global function is okay. Also, if we're actually going to do this all the way, separate files for each language would probably be for the best.

The structure looks good though!

Collaborator

mc10 commented Jul 15, 2015

Twinkle.lang.parse is probably too long—you don't want to clutter up the code. In this case I think a short global function is okay. Also, if we're actually going to do this all the way, separate files for each language would probably be for the best.

The structure looks good though!

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Jul 15, 2015

Contributor

@mc10 what do you recommend for the function name? Twinkle.__() ?

Also, as far as the messages, one alternative is to have every module contain its own messages (at the end). Another is to create separate JS file for each module (so then each module becomes two file, one with code, one with messages). I vote for the first, but I appreciate feedback.

Contributor

Huji commented Jul 15, 2015

@mc10 what do you recommend for the function name? Twinkle.__() ?

Also, as far as the messages, one alternative is to have every module contain its own messages (at the end). Another is to create separate JS file for each module (so then each module becomes two file, one with code, one with messages). I vote for the first, but I appreciate feedback.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Jul 15, 2015

Collaborator

In my "twinklelocal" branch I used the approach of aliasing a function by passing it into the global wrapper function for the module. Check it out.

I would suggest to keep the modules in separate files, as they are now, and move the localisation material into its own file. This means that, when an administrator is localising Twinkle to their own wiki, they will only need to modify the one file.

Collaborator

atlight commented Jul 15, 2015

In my "twinklelocal" branch I used the approach of aliasing a function by passing it into the global wrapper function for the module. Check it out.

I would suggest to keep the modules in separate files, as they are now, and move the localisation material into its own file. This means that, when an administrator is localising Twinkle to their own wiki, they will only need to modify the one file.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Jul 15, 2015

Collaborator

PS: We have an IRC channel #wikipedia-userscripts which you can use. I am sometimes online there.

Collaborator

atlight commented Jul 15, 2015

PS: We have an IRC channel #wikipedia-userscripts which you can use. I am sometimes online there.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Jul 15, 2015

Contributor

On my way to that IRC channel. A link to your "twinklelocal" branch would be helpful as well.

Contributor

Huji commented Jul 15, 2015

On my way to that IRC channel. A link to your "twinklelocal" branch would be helpful as well.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Jul 15, 2015

Contributor

Please see Huji@be1a412

The locale is set only once (and in reality, it wouldn't be hard-coded, but would rather be fetched from the wiki's config.

I am using jquery.i18n which is a module created for Wikimedia specifically, by James Forrest; it is now part of ULS (which all Wikipedia's use) and very soon will be part of core. You need to add it as a dependency like this.

Because I envision jquery.i18n to be used by other Gadgets too, I am prefixing all Twinkle messages with tw-

Do you like this style? Before I invest more time in it, please let me know if there is something that needs to be changed. My plan is to finish the entire i18nization in about one week. Once merged into core, then I will start working on adding l10n too (localization will be useful when different wikis use different criteria for speedy deletion, etc. I am keeping l10n separate from i18n for good reasons).

Contributor

Huji commented Jul 15, 2015

Please see Huji@be1a412

The locale is set only once (and in reality, it wouldn't be hard-coded, but would rather be fetched from the wiki's config.

I am using jquery.i18n which is a module created for Wikimedia specifically, by James Forrest; it is now part of ULS (which all Wikipedia's use) and very soon will be part of core. You need to add it as a dependency like this.

Because I envision jquery.i18n to be used by other Gadgets too, I am prefixing all Twinkle messages with tw-

Do you like this style? Before I invest more time in it, please let me know if there is something that needs to be changed. My plan is to finish the entire i18nization in about one week. Once merged into core, then I will start working on adding l10n too (localization will be useful when different wikis use different criteria for speedy deletion, etc. I am keeping l10n separate from i18n for good reasons).

@kaldari

This comment has been minimized.

Show comment
Hide comment
@kaldari

kaldari Aug 14, 2015

Contributor

I would strongly suggest using JSON for the i18n data. This will open up possibilities like using the JsonConfig extension to provide a nice UI for editing the messages on-wiki and possibly porting Twinkle into a MediaWiki extension one day (all MediaWIki extensions use JSON files for storing i18n data, separated by language, e.g. en.json, de.json, etc.).

Contributor

kaldari commented Aug 14, 2015

I would strongly suggest using JSON for the i18n data. This will open up possibilities like using the JsonConfig extension to provide a nice UI for editing the messages on-wiki and possibly porting Twinkle into a MediaWiki extension one day (all MediaWIki extensions use JSON files for storing i18n data, separated by language, e.g. en.json, de.json, etc.).

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 15, 2015

Contributor

This is part of the reason I have been stalling on this project. I want to solicit more feedback. We can't have it both ways: we have to either split the files by language (en.json, de.json, ...), or by module (one for Twinkleprod, one for TwinkleCSD, ...). I am personally in favor of the former, and atlight seems to like the latter. We need to make this decision now, before I create the files.

Contributor

Huji commented Aug 15, 2015

This is part of the reason I have been stalling on this project. I want to solicit more feedback. We can't have it both ways: we have to either split the files by language (en.json, de.json, ...), or by module (one for Twinkleprod, one for TwinkleCSD, ...). I am personally in favor of the former, and atlight seems to like the latter. We need to make this decision now, before I create the files.

@Hello71

This comment has been minimized.

Show comment
Hide comment
@Hello71

Hello71 Aug 15, 2015

@Huji split by language is better. see: gettext. this way makes much more sense especially for more languages; each person needs to edit their own set of languages, instead of all the modules then searching for their languages.

Hello71 commented Aug 15, 2015

@Huji split by language is better. see: gettext. this way makes much more sense especially for more languages; each person needs to edit their own set of languages, instead of all the modules then searching for their languages.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 15, 2015

Contributor

Sounds good. In that case, I will make it happen in a few days (in my own fork of course).
One important thing I noticed is this: i18n should be called BEFORE any values are set. Right now, twinkle sets certain config variables, including the one that determines the portlet's label ("TW") before anything else is loaded. I am going to change it such that i18n is loaded before anything else.

Contributor

Huji commented Aug 15, 2015

Sounds good. In that case, I will make it happen in a few days (in my own fork of course).
One important thing I noticed is this: i18n should be called BEFORE any values are set. Right now, twinkle sets certain config variables, including the one that determines the portlet's label ("TW") before anything else is loaded. I am going to change it such that i18n is loaded before anything else.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Aug 15, 2015

Collaborator

Please see also the discussion re this issue at https://phabricator.wikimedia.org/T108426. If you think you will have time to complete work on this issue within the next few months, please comment there.

There is actually very little pure i18n in Twinkle. Most is actually localisation (depends on the individual wiki, not just the language). For example, just about every string in every module should be customizable by the wiki, perhaps with the exception of some standard error messages.

What I actually envisage is a separate file for each language-module pair... is that a bit much?

Collaborator

atlight commented Aug 15, 2015

Please see also the discussion re this issue at https://phabricator.wikimedia.org/T108426. If you think you will have time to complete work on this issue within the next few months, please comment there.

There is actually very little pure i18n in Twinkle. Most is actually localisation (depends on the individual wiki, not just the language). For example, just about every string in every module should be customizable by the wiki, perhaps with the exception of some standard error messages.

What I actually envisage is a separate file for each language-module pair... is that a bit much?

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 16, 2015

Contributor

@atlight I think it is an overkill to have one file for each language-module pair. Instead, I think I will name the messages in such a way that you can easily determine which module they belong to (e.g. "tw-csd-...") but keep them all in the same file for each language.

As for i18n vs l10n, your point is well taken. Different modules may not apply to certain wikis (e.g. not every wiki has a PROD policy), and certain module features may need to be modified or deactivated (e.g. not all tags in the Tags module have an equivalent in every other wiki, and there are other tags that certain wikis have that En WP doesn't).

Nonetheless, the overlaps is so large that I think simply enabling i18n can be a huge boost in enabling the use of TW in many wikis. That is my humble opinion, and I hope this discussion will lead us to a consensus; preferably before I start spending hours on i18n.

Lastly, I will definitely check out T198426 and comment there if I can help.

Contributor

Huji commented Aug 16, 2015

@atlight I think it is an overkill to have one file for each language-module pair. Instead, I think I will name the messages in such a way that you can easily determine which module they belong to (e.g. "tw-csd-...") but keep them all in the same file for each language.

As for i18n vs l10n, your point is well taken. Different modules may not apply to certain wikis (e.g. not every wiki has a PROD policy), and certain module features may need to be modified or deactivated (e.g. not all tags in the Tags module have an equivalent in every other wiki, and there are other tags that certain wikis have that En WP doesn't).

Nonetheless, the overlaps is so large that I think simply enabling i18n can be a huge boost in enabling the use of TW in many wikis. That is my humble opinion, and I hope this discussion will lead us to a consensus; preferably before I start spending hours on i18n.

Lastly, I will definitely check out T198426 and comment there if I can help.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Aug 16, 2015

Collaborator

The only reason I was against organising the i18n/l10n data into files by language is because I don't expect other wikis' config data to be kept in this repository. I certainly don't want to have to manage it. My vision is to have only enwiki's config data here, and other wikis can keep theirs elsewhere. And as I said above, most i18n is actually wiki-specific, so I'm not sure that it makes sense to store even that in this repository.

But let's not worry about that for now. Start coding the way you see fit, and we can discuss it further once you have made a start. I'm keen to see how your first module turns out.

Just a tip - there's a reason my initial "twinklelocal" effort started off with the Shared IP module - it's the shortest of the lot (apart from "diff", which isn't very interesting). It's probably the best one for getting your infrastructure up and running.

Collaborator

atlight commented Aug 16, 2015

The only reason I was against organising the i18n/l10n data into files by language is because I don't expect other wikis' config data to be kept in this repository. I certainly don't want to have to manage it. My vision is to have only enwiki's config data here, and other wikis can keep theirs elsewhere. And as I said above, most i18n is actually wiki-specific, so I'm not sure that it makes sense to store even that in this repository.

But let's not worry about that for now. Start coding the way you see fit, and we can discuss it further once you have made a start. I'm keen to see how your first module turns out.

Just a tip - there's a reason my initial "twinklelocal" effort started off with the Shared IP module - it's the shortest of the lot (apart from "diff", which isn't very interesting). It's probably the best one for getting your infrastructure up and running.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 31, 2015

Contributor

All right I finally decided to start with jquery.i18n for now so we have something to discuss. Please see Huji@6982ff0

Note that any initialization that involves interface messages must be done after i18n is initialized therefore I had to move some parts of the code into initialize() functions and call them when the module is loaded.

Also note that not all messages are i18n'ed in this commit. There are two reasons. The less important one is I didn't have the time. The more important one is if a message contains the string '{{', jquery.i18n tries to parse what comes after it and that is a problem with the SharedIP module of twinkle, because it has strings that start with {{.

I have posted an issue on jquery.i18n asking for a solution. Unless they provide a solution quickly, we may be better off creating our own i18n module.

To test, please check this out: https://fawp.wmflabs.org/wiki/User_talk:1.2.3.4 (after you create an account and enable Twinkle in Special:Preferences of course!) and also https://fawp.wmflabs.org/wiki/User_talk:1.2.3.4?uselang=fa (where you will see that the portlet's label is not TW anymore and changes to "توینکل" as expected).

Comments are appreciated.

Contributor

Huji commented Aug 31, 2015

All right I finally decided to start with jquery.i18n for now so we have something to discuss. Please see Huji@6982ff0

Note that any initialization that involves interface messages must be done after i18n is initialized therefore I had to move some parts of the code into initialize() functions and call them when the module is loaded.

Also note that not all messages are i18n'ed in this commit. There are two reasons. The less important one is I didn't have the time. The more important one is if a message contains the string '{{', jquery.i18n tries to parse what comes after it and that is a problem with the SharedIP module of twinkle, because it has strings that start with {{.

I have posted an issue on jquery.i18n asking for a solution. Unless they provide a solution quickly, we may be better off creating our own i18n module.

To test, please check this out: https://fawp.wmflabs.org/wiki/User_talk:1.2.3.4 (after you create an account and enable Twinkle in Special:Preferences of course!) and also https://fawp.wmflabs.org/wiki/User_talk:1.2.3.4?uselang=fa (where you will see that the portlet's label is not TW anymore and changes to "توینکل" as expected).

Comments are appreciated.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Aug 31, 2015

Collaborator

This is a good start, Huji.

There are two main issues I have with this, such that I would not be prepared to merge any code that uses this structure:

Firstly, you're missing the localisation aspect. What you are currently doing would be good if, say, we wanted to allow Persian speakers to use Twinkle on English Wikipedia. But that is not a goal of the project, as I see it; instead, we want to make Twinkle usable in the context of other wikis, which this does not achieve.

For example, instead of localising the template names and labels of the individual shared IP templates, you need to provide a way for each wiki to substitute its own list of shared IP templates. For example, imagine a hypothetical project "English Wikicooking". It has three shared IP tags: {{shared IP}}, {{shared IP restaurant}}, {{shared IP retail}}. The {{shared IP}} template supports only the "organisation" parameter, and the other two support only the "contact" parameter. With your proposed patch, there is no way for English Wikicooking to implement the shared IP module to suit their wiki's needs.

Secondly, it's not clear why you are moving stuff around in twinkle.js. The whole thing gets wrapped with an anonymous function by ResourceLoader in the end. I suggest you leave the config settings stuff where it is, and simply override the default (English) values as required in your initialisation function.

And yes, if there's no way to escape {{ in jQuery localisation strings, that's a big problem. Can you link to the issue?

Collaborator

atlight commented Aug 31, 2015

This is a good start, Huji.

There are two main issues I have with this, such that I would not be prepared to merge any code that uses this structure:

Firstly, you're missing the localisation aspect. What you are currently doing would be good if, say, we wanted to allow Persian speakers to use Twinkle on English Wikipedia. But that is not a goal of the project, as I see it; instead, we want to make Twinkle usable in the context of other wikis, which this does not achieve.

For example, instead of localising the template names and labels of the individual shared IP templates, you need to provide a way for each wiki to substitute its own list of shared IP templates. For example, imagine a hypothetical project "English Wikicooking". It has three shared IP tags: {{shared IP}}, {{shared IP restaurant}}, {{shared IP retail}}. The {{shared IP}} template supports only the "organisation" parameter, and the other two support only the "contact" parameter. With your proposed patch, there is no way for English Wikicooking to implement the shared IP module to suit their wiki's needs.

Secondly, it's not clear why you are moving stuff around in twinkle.js. The whole thing gets wrapped with an anonymous function by ResourceLoader in the end. I suggest you leave the config settings stuff where it is, and simply override the default (English) values as required in your initialisation function.

And yes, if there's no way to escape {{ in jQuery localisation strings, that's a big problem. Can you link to the issue?

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 31, 2015

Contributor

As for the first issue: I think the best approach to enable both i18n and l10n is to make sure all our modules start with an initialization phase where the "default" values are loaded. So if the templates used in Shared IP for a different language (or wiki) are different, you can override the default config locally. I will try to make an example of it on my fork.
As for the second: the reason I moved stuff around was because my philosophy was that nothing, even the default values, should not set an interface message before i18n is loaded. You can do it the other way too: load i18n afterwards, and then override the default configs. I think it is redundant but if you think that is better coding, I will do so.

Contributor

Huji commented Aug 31, 2015

As for the first issue: I think the best approach to enable both i18n and l10n is to make sure all our modules start with an initialization phase where the "default" values are loaded. So if the templates used in Shared IP for a different language (or wiki) are different, you can override the default config locally. I will try to make an example of it on my fork.
As for the second: the reason I moved stuff around was because my philosophy was that nothing, even the default values, should not set an interface message before i18n is loaded. You can do it the other way too: load i18n afterwards, and then override the default configs. I think it is redundant but if you think that is better coding, I will do so.

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Aug 31, 2015

Collaborator

I guess my concern with the second point is, while your approach is probably necessary for non-ResourceLoader scenarios, it is probably not necessary in RL (real life ResourceLoader) scenarios. (I say "probably" because JavaScript loading can a very fickle thing!) I don't really mind that much, though.

The first issue is more of a concern. My idea was to get rid of the enwiki-specific template stuff from the module entirely, so that the module is mostly wiki-agnostic. (Some of the logic may still have to remain wiki-specific, but that shouldn't be too great an issue in Shared IP.)

I'd at least like to see an attempt at implementing shared IP for another wiki (I don't know if fawiki has shared IP templates; if not, at least just implement it for my Wikicooking example, or another real wiki that does have shared IP templates.) I'll be interested to see the example in your fork.

Collaborator

atlight commented Aug 31, 2015

I guess my concern with the second point is, while your approach is probably necessary for non-ResourceLoader scenarios, it is probably not necessary in RL (real life ResourceLoader) scenarios. (I say "probably" because JavaScript loading can a very fickle thing!) I don't really mind that much, though.

The first issue is more of a concern. My idea was to get rid of the enwiki-specific template stuff from the module entirely, so that the module is mostly wiki-agnostic. (Some of the logic may still have to remain wiki-specific, but that shouldn't be too great an issue in Shared IP.)

I'd at least like to see an attempt at implementing shared IP for another wiki (I don't know if fawiki has shared IP templates; if not, at least just implement it for my Wikicooking example, or another real wiki that does have shared IP templates.) I'll be interested to see the example in your fork.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 31, 2015

Contributor

We have to decide which parts can be wiki-specific and which parts cannot. Take SharedIP as an example; do we only want to allow the templates to be wiki specific (my thought), or both the templates and the textboxes (e.g. one wiki might decide they need a fourth textbox in addition to owner, host and contact info)? Do we want the logic of disabling textboxes to be customizable? (right now if you pick Shared IP edu the third textbox gets enabled) And if so, how?

The more flexible we make it, the more complex it becomes but then you can have Twinkle on Wikimedia and non-Wikimedia wikis (as long as you are willing to configure it with all its complexities). If we keep it very simple then we will be limited, perhaps only to Wikipedias, but it would be much easier to adopt.

Right now, my thought is to allow only customizing the template list and forgo the entire logic of disabling textboxes (as it changes from wiki to wiki). One might not like the idea of removing the logic that is already there, but we have to realize that what we like is not important; having a tool that is easily usable to a larger group is important.

TL;DR: Twinkle is highly en-wiki biased. If we are wiling to make it i18n'ed and l10n'ed, we have to swallow the bitter pill of losing some unnecessary en-wiki specific features (like the textbox that is disabled).

Contributor

Huji commented Aug 31, 2015

We have to decide which parts can be wiki-specific and which parts cannot. Take SharedIP as an example; do we only want to allow the templates to be wiki specific (my thought), or both the templates and the textboxes (e.g. one wiki might decide they need a fourth textbox in addition to owner, host and contact info)? Do we want the logic of disabling textboxes to be customizable? (right now if you pick Shared IP edu the third textbox gets enabled) And if so, how?

The more flexible we make it, the more complex it becomes but then you can have Twinkle on Wikimedia and non-Wikimedia wikis (as long as you are willing to configure it with all its complexities). If we keep it very simple then we will be limited, perhaps only to Wikipedias, but it would be much easier to adopt.

Right now, my thought is to allow only customizing the template list and forgo the entire logic of disabling textboxes (as it changes from wiki to wiki). One might not like the idea of removing the logic that is already there, but we have to realize that what we like is not important; having a tool that is easily usable to a larger group is important.

TL;DR: Twinkle is highly en-wiki biased. If we are wiling to make it i18n'ed and l10n'ed, we have to swallow the bitter pill of losing some unnecessary en-wiki specific features (like the textbox that is disabled).

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 31, 2015

Contributor

@atlight here is another step forward. Check my fork again please and test on https://fawp.wmflabs.org/w/index.php?title=User_talk:1.2.3.4&action=edit&redlink=1 and https://fawp.wmflabs.org/w/index.php?title=User_talk:1.2.3.4&action=edit&redlink=1&uselang=de

As you can see, I am not putting the default settings defined in Twinkle.js in a function any more. I simply override Twinkle.defaultConfig.twinkle.portletName further down.

Also, as you can see, as long as the config of each module is in a property which can be overriden before the module is loaded, one can easily localize the modules. In this case, the DE version will have a much shorter list of templates for SharedIP.

All the stuff that is currently added in the middle of Twinkle.js will eventually move into a module called Gadget-twinklelocalize.js for a cleaner look

Also, I switched from jquery.i18n to jquery-i18n (dash versus dot) because it didn't have the issues with "{{". I further customized jquery-18n. The original version is on https://github.com/recurser/jquery-i18n

Contributor

Huji commented Aug 31, 2015

@atlight here is another step forward. Check my fork again please and test on https://fawp.wmflabs.org/w/index.php?title=User_talk:1.2.3.4&action=edit&redlink=1 and https://fawp.wmflabs.org/w/index.php?title=User_talk:1.2.3.4&action=edit&redlink=1&uselang=de

As you can see, I am not putting the default settings defined in Twinkle.js in a function any more. I simply override Twinkle.defaultConfig.twinkle.portletName further down.

Also, as you can see, as long as the config of each module is in a property which can be overriden before the module is loaded, one can easily localize the modules. In this case, the DE version will have a much shorter list of templates for SharedIP.

All the stuff that is currently added in the middle of Twinkle.js will eventually move into a module called Gadget-twinklelocalize.js for a cleaner look

Also, I switched from jquery.i18n to jquery-i18n (dash versus dot) because it didn't have the issues with "{{". I further customized jquery-18n. The original version is on https://github.com/recurser/jquery-i18n

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Sep 21, 2015

Contributor

Finally got a chance to clean up my code. Please see #292 and use the following links for a demo:

https://fawp.wmflabs.org/w/index.php
https://fawp.wmflabs.org/w/index.php?uselang=de
https://fawp.wmflabs.org/w/index.php?title=User_talk:1.2.3.4&action=edit&redlink=1
https://fawp.wmflabs.org/w/index.php?title=User_talk:1.2.3.4&action=edit&redlink=1&uselang=de

With the latter two links, make sure you bring up the Shared IP dialog to notice the difference in content (localized).

Contributor

Huji commented Sep 21, 2015

Finally got a chance to clean up my code. Please see #292 and use the following links for a demo:

https://fawp.wmflabs.org/w/index.php
https://fawp.wmflabs.org/w/index.php?uselang=de
https://fawp.wmflabs.org/w/index.php?title=User_talk:1.2.3.4&action=edit&redlink=1
https://fawp.wmflabs.org/w/index.php?title=User_talk:1.2.3.4&action=edit&redlink=1&uselang=de

With the latter two links, make sure you bring up the Shared IP dialog to notice the difference in content (localized).

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Sep 21, 2015

Contributor

At this point we need to decide if we want to keep the EN WP-specific features in the modules as default values, or if we want to even move those into the localization module. I vote for keeping them where they are, but comments are certainly welcome.

We should also decide if you just want me to cleanup the code in #292 so it is actually pulled into the repo, or if you rather I spend time i18nizing every module first. I am undecided here, and regardless of which we decide I would appreciate help in the i18nization of modules.

Contributor

Huji commented Sep 21, 2015

At this point we need to decide if we want to keep the EN WP-specific features in the modules as default values, or if we want to even move those into the localization module. I vote for keeping them where they are, but comments are certainly welcome.

We should also decide if you just want me to cleanup the code in #292 so it is actually pulled into the repo, or if you rather I spend time i18nizing every module first. I am undecided here, and regardless of which we decide I would appreciate help in the i18nization of modules.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Mar 8, 2016

Contributor

I created a new pull request showing where I am right now (there was a huge hiatus in my work on this):

#320

It moves l10n and i18n to separate files, keeping all messages in the same place. We can decide if we only want to include the english messages, or that for all languages (we can use Translatewiki for translations if need be). I vote for EN only. For now, I included some DE sample so you can see how things will look like.

Comments are appreciated.

Contributor

Huji commented Mar 8, 2016

I created a new pull request showing where I am right now (there was a huge hiatus in my work on this):

#320

It moves l10n and i18n to separate files, keeping all messages in the same place. We can decide if we only want to include the english messages, or that for all languages (we can use Translatewiki for translations if need be). I vote for EN only. For now, I included some DE sample so you can see how things will look like.

Comments are appreciated.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Mar 14, 2016

Contributor

I have explained my concerns as comments on the pull request above, but I want to summarize them here:

We all agree it is best if we don't have ANY project-specific (e.g. ENWP-specific) logic in the Twinkle code. The logic should be in the localization file. But to change the entire Twinkle in that way is really hard and takes lots of time.

My approach is: let's first not move any of the logic, but just take a baby step: move all messages out and make them easier to translate. Once that is done, we will move the callbacks in the next step. Is that reasonable?

Contributor

Huji commented Mar 14, 2016

I have explained my concerns as comments on the pull request above, but I want to summarize them here:

We all agree it is best if we don't have ANY project-specific (e.g. ENWP-specific) logic in the Twinkle code. The logic should be in the localization file. But to change the entire Twinkle in that way is really hard and takes lots of time.

My approach is: let's first not move any of the logic, but just take a baby step: move all messages out and make them easier to translate. Once that is done, we will move the callbacks in the next step. Is that reasonable?

@atlight

This comment has been minimized.

Show comment
Hide comment
@atlight

atlight Mar 14, 2016

Collaborator

I largely agree with your approach, except it misses some detail.

Twinkle localisation will involve (from simplest to most complicated):

  • Project-independent strings ("Twinkle", "Submit Query", "Reason:", "Notify page creator if possible", etc)
  • Project-dependent strings ("Criteria for speedy deletion", "Semi-protection", etc)
  • Miscellaneous project-dependent parameters (whether to enable the PROD module on this project)
  • Project-dependent objects (lists of templates, etc)
  • Project-dependent logic (callbacks, etc)

Which of those levels do you want to attempt? I imagine you'd be interested in the first two, and possibly the next two, but not the last one for now.

Collaborator

atlight commented Mar 14, 2016

I largely agree with your approach, except it misses some detail.

Twinkle localisation will involve (from simplest to most complicated):

  • Project-independent strings ("Twinkle", "Submit Query", "Reason:", "Notify page creator if possible", etc)
  • Project-dependent strings ("Criteria for speedy deletion", "Semi-protection", etc)
  • Miscellaneous project-dependent parameters (whether to enable the PROD module on this project)
  • Project-dependent objects (lists of templates, etc)
  • Project-dependent logic (callbacks, etc)

Which of those levels do you want to attempt? I imagine you'd be interested in the first two, and possibly the next two, but not the last one for now.

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Mar 14, 2016

Contributor

That is correct. I think it would be logical to do 1, 2 and 4 before we
tackle 3 and 5.

On Sun, Mar 13, 2016 at 8:37 PM, This, that and the other <
notifications@github.com> wrote:

I largely agree with your approach, except it misses some detail.

Twinkle localisation will involve (from simplest to most complicated):

  • Project-independent strings ("Twinkle", "Submit Query", "Reason:",
    "Notify page creator if possible", etc)
  • Project-dependent strings ("Criteria for speedy deletion",
    "Semi-protection", etc)
  • Miscellaneous project-dependent parameters (whether to enable the
    PROD module on this project)
  • Project-dependent objects (lists of templates, etc)
  • Project-dependent logic (callbacks, etc)

Which of those levels do you want to attempt? I imagine you'd be
interested in the first two, and possibly the next two, but not the last
one for now.


Reply to this email directly or view it on GitHub
#129 (comment).

Contributor

Huji commented Mar 14, 2016

That is correct. I think it would be logical to do 1, 2 and 4 before we
tackle 3 and 5.

On Sun, Mar 13, 2016 at 8:37 PM, This, that and the other <
notifications@github.com> wrote:

I largely agree with your approach, except it misses some detail.

Twinkle localisation will involve (from simplest to most complicated):

  • Project-independent strings ("Twinkle", "Submit Query", "Reason:",
    "Notify page creator if possible", etc)
  • Project-dependent strings ("Criteria for speedy deletion",
    "Semi-protection", etc)
  • Miscellaneous project-dependent parameters (whether to enable the
    PROD module on this project)
  • Project-dependent objects (lists of templates, etc)
  • Project-dependent logic (callbacks, etc)

Which of those levels do you want to attempt? I imagine you'd be
interested in the first two, and possibly the next two, but not the last
one for now.


Reply to this email directly or view it on GitHub
#129 (comment).

@Huji Huji referenced a pull request that will close this issue Mar 14, 2016

Open

Bring i18n and l10n features to Twinkle #329

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 28, 2016

Contributor

Can we please revisit this? I have a pull request that I want to build upon, so long as there is interest in this.

Contributor

Huji commented Aug 28, 2016

Can we please revisit this? I have a pull request that I want to build upon, so long as there is interest in this.

@Siddhartha-Ghai

This comment has been minimized.

Show comment
Hide comment
@Siddhartha-Ghai

Siddhartha-Ghai Aug 5, 2018

It's 2018 and maintaining Twinkle for different wikis is still a tough job. Even partial fixes for this could make it a lot easier.
What happened to this then? Do we build upon Huji's work, or do we follow a different path?
@atlight

Siddhartha-Ghai commented Aug 5, 2018

It's 2018 and maintaining Twinkle for different wikis is still a tough job. Even partial fixes for this could make it a lot easier.
What happened to this then? Do we build upon Huji's work, or do we follow a different path?
@atlight

@Huji

This comment has been minimized.

Show comment
Hide comment
@Huji

Huji Aug 5, 2018

Contributor

See relevant discussion here: https://phabricator.wikimedia.org/T110148

I refrain from working on this until I see actual support (like "do this") rather than mere criticism (like "don't do that") and a true desire for having a partial solution in production (as opposed to expecting a complete solution before pushing anything into production)

Contributor

Huji commented Aug 5, 2018

See relevant discussion here: https://phabricator.wikimedia.org/T110148

I refrain from working on this until I see actual support (like "do this") rather than mere criticism (like "don't do that") and a true desire for having a partial solution in production (as opposed to expecting a complete solution before pushing anything into production)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment