51
trabis
Re: Translation Teams on Transifex
  • 2013/1/13 12:59

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


I was thinking in taking the pt_PT language hoping that I could reuse the already translated strings from pt_BR.
Unfortunately, transifex only allows forking a language. Since the pt_PT language was already created, it did not allow me to import pt_BR translations. There is as option to display the string translated in pt_BR along with the source but the "copy source" button does not allow to copy the pt_BR. Resuming, I need to go copy/pasting the pt_BR translations and the pt_BR team will need to go copy/pasting pt_PT translations.

Due to this problem, it does not make sense to have 2 different projects. You can drop the pt_PT language on transifex. I'll be helping in the pt_BR team.

It is also a pain to know that transifex will not allow the use of class based translations. If we use class based translations on 2.6. we will have to create an export/import tool . Class to INI, INI to class. It is easy to do such tool, but it an extra step for translators. In the other hand, you will have only one file per language to worry about.



52
trabis
Re: xlanguage will not work with profiles
  • 2013/1/13 12:35

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

irmtfan wrote:
Yes i also think we should drop the legacy fields.
but you know some of those fields are unique and are used widely in core/modules.
eg: posts, theme, umode, uorder
so the new profile module should care about them too. is that possible to make other modules be aware of these unique fields?
some fields are useless now. eg:user_msnm, user_icq are dead.

There is already a userconfigs module in 2.6.0 that will be used to hold configs by user. For example, the comments module will be using userconfigs table instead of user table. All configs that are not supposed to be displayed on profile pages (no visibility/ no permissions) can be moved into userconfigs (theme, receive emails, show email, etc)

I think 'posts' could be managed by other module, perhaps a refactored 'mypoints' could do it.



53
trabis
Re: Transifex and rant
  • 2013/1/12 15:14

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

Trabis, no matter how much J! core developers are busy with their specific tasks on sub-projects in extending and developing Joomla! in the way to be made Number 1 choice for CMS, they are responding to community requests, not using someone like Mamba to translate what are u doing and where.

As I said before, feature requests will be handled on alpha 3. I'll respond to community in due time. I don't use Mamba to translate what I'm doing. If Mamba decides to translate what I'm doing it is his choice. It is his dish.

Quote:

Yeah I've got reply from u, very unsatisfying but a reply.
"We will do that, bcz we decided in that way, if not works in future - we will replace it"

If you are going to quote me, quote me, don't pretend you are quoting me.

If my unsatisfying reply was regarding organization:
You are not in the core team. If the core team is pleased with their organization, let them be. It is their dish.
If you are on translation team, you should look for organization in there. I don't care how translation team operates. It is their dish.

[end of if]

Quote:

Mage: When I got negative reply by someone, I reply him in my way, by my words, I don't tolerate censorship and such idiotic politics.

Right! And you should reply in the same thread, so people don't find out you are "quoting" them behind their backs.



54
trabis
Re: xlanguage will not work with profiles
  • 2013/1/12 14:43

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


@irmtfan,
Perhaps we should make profile a required module and not uninstallable (like system module). All other modules should use the profile api to get user data.
On upgrade, users table would be renamed to profile_profile and all none required fields would become editable/removable. For unremovable fields we can look at facebook and many other sites:

Facebook: firstname, lastname, email, password, birthdate and gender
Linkedin: firstname, lastname, email, password
hi5: firstname, lastname, email, password, country, city, language, birthdate, gender
Myspace: firstname, lastname, email, password, birthdate, gender, others
Tumblr : username, email, password
Twitter: fullname, email, password
Delicious: Displayname, username, email, password
Stackexchange: email, password, displayname(optional)
reddit: username, email, password

This way we could remove duplicate code for registration/login/user activity/avatar upload and have a unique api for profiles.



55
trabis
Re: Block for specific day
  • 2013/1/12 13:32

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


@sabahan
As far a I remember, Mytabs only allows one range of time, you would have to set the range every week :(



56
trabis
Re: Block for specific day
  • 2013/1/12 1:06

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

zyspec wrote:
You can just use the PHP date() function to find the day of the week and then either 'return' or display based on the day of week. For example:

if (== $date('w')) {
  
//display Friday's info
  
echo "It's Friday!";
}


And if the block already exists in a module, you can edit the block function.
Example for system_blocks.php
function b_system_online_show()
{
if (
!= date('w')) {
  
//if it is not Friday don't display the block
  
return false;
}
//Display code here
}



57
trabis
Re: Bootstrap and forms
  • 2013/1/11 18:50

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:
Tarik wrote: Hello, i'm at the moment messing with the 2.6 version of xoops and wanted to try Bootstrap potential in Modules which was amazing but still i didnt know how to use a portion of it, you can see it herehttp://jasny.github.com/bootstrap/javascript.html#buttons must i code the form with javascript. mainly toggleable buttons and how to include them in forms, can someone informed give some guidance.
You can install the codex module and see the example on form.php If you need to insert javascript in one form element you can use the setExtra() Example of usage in publisher module:
$butt_cancel = new XoopsFormButton(''''_CO_PUBLISHER_CANCEL'button');
$butt_cancel->setExtra('onclick="history.go(-1)"');
$form->addElement($butt_cancel);
If you need to insert a inline script you can use XoopsFormlabel or XoopsFormRaw. Example from publisher
$js_data = new XoopsFormLabel('''
<script type= "text/javascript">/*<![CDATA[*/
$(document).ready(function(){
    var button = $("#publisher_upload_button"), interval;
    new AjaxUpload(button,{
        action: "' 
PUBLISHER_URL '/include/ajax_upload.php", // I disabled uploads in this example for security reasons
        responseType: "text/html",
        name: "publisher_upload_file",
        onSubmit : function(file, ext){
            // change button text, when user selects file
            $("#publisher_upload_message").html(" ");
            button.html("<img src='' . PUBLISHER_URL . '
/images/loadingbar.gif'/>"); this.setData({
                "image_nicename": $("#image_nicename").val(),
                "imgcat_id" : $("#imgcat_id").val()
            });
            // If you want to allow uploading only 1 file at time,
            // you can disable upload button
            this.disable();
            interval = window.setInterval(function(){
            }, 200);
        },
        onComplete: function(file, response){
            button.text("' 
_CO_PUBLISHER_IMAGE_UPLOAD_NEW '");
            window.clearInterval(interval);
            // enable upload button
            this.enable();
            // add file to the list
            var result = eval(response);
            if (result[0] == "success") {
                 $("#image_item").append("<option value='" + result[1] + "' selected='
selected'>" + result[2] + "</option>");
                 publisher_updateSelectOption('
image_item', 'image_featured');
                 showImgSelected('
image_display', 'image_item', 'uploads/images/', '', '' . XOOPS_URL . '')
            } else {
                 $("#publisher_upload_message").html("<div class='
errorMsg'>" + result[1] + "</div>");
            }
        }
    });
});
/*]]>*/</script>
'
);
$form->addElement($js_data);
Btw, when you look into the form example, you will see that the form is padded to the right. Can you find a way to fix it, I've tried for hours with no success :(



58
trabis
Re: XOOPS 2.6.0 Alpha 1 Testing
  • 2013/1/11 18:17

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

Tarik wrote:

btw how do i activate error log?

You can install the logger module to enable debug.

Thanks for the report, I'll check it.



59
trabis
Re: Module Standardization Team - looking for volunteers
  • 2013/1/11 13:59

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

alain01 wrote:
Is it posible to use the overloaded template with php ?
For exemple, overloaded the functions in the file :
/themes/my-theme/modules/system/functions/system_blocks.php or if not like that, with this idea !


I don't think is good idea to overwrite php files. Even with templates there is problems. A module developer can change the php code of a block and your template will stop working. For php it may be even worst, as some of the functions provided by that module may be deleted or have other behaviour.
A better way would be to add a preload event on each function so they can be hooked by other modules/themes.

I think a better solution may be possible when we have controllers/response/router classes implemented on core. Before each module/action we will be able to trigger events. The theme could catch the event for system_blocks and change the response (changing the template or replacing even the action for example)







60
trabis
Re: xlanguage will not work with profiles
  • 2013/1/11 13:40

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

irmtfan wrote:

But i still think it is not good because a 1 language user will see strange and weird constants instead of real titles in his own language.

IMO the better way is to remove edit title feature as i said before. so nobody can see and change them.


You can use constant('_US_OCCUPATION') to display the translation and not "strange and weird constants". We can also look to see if a given field is holding a constant or not when displaying in the front side, but...

I did not realized that fields were editable so now I think there is no bug. The developer is excused! Creating different routine to solve the legacy fields is not good solution because it does not fix the custom fields.
Since we are talking about xlanguage, the best approach would be to use xlanguage tags in the fields titles as irmtfan proposes.




TopTop
« 1 ... 3 4 5 (6) 7 8 9 ... 190 »



Login

Who's Online

326 user(s) are online (206 user(s) are browsing Support Forums)


Members: 0


Guests: 326


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits