@laoneo when I started the calendar I had everything as data attributes: https://github.com/dgt41/joomla-cms/blob/d3982d92771d8444f2e00f876e5b5eed13c462aa/layouts/joomla/form/field/calendar.php

I really don't remember what was the reason for moving to js files (there are a lot of comments there and a few more in my mailbox...)

we have already started to get in core the specific language js files... just hurry up if we have to stop this process!!!!!!
also, if you pursue, should be used the existing xx-XX.ini strings and NOT new lib ini ones

If you agree that this is the way to go, then I will finish it over
weekend. This will add a dependency to JText in the calendar js.

Jeam marie, which strings are you talking about?

On Dec 9, 2016 20:33, "infograf768" notifications@github.com wrote:

we have already started to get in core the specific language js files...
just hurry up if we have to stop this process!!!!!!
also, if you pursue, should be used the existing xx-XX.ini strings and NOT
new lib ini ones

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#13150 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPUwH_1C6f5FSlRkn6KBtSOuJ226htEks5rGaz1gaJpZM4LJPGp
.

i am not in favour as this process has started and is going on. TTs are working on it. suddenly changing is a p... in the a...
for the existing strings, see here for days and months
https://github.com/joomla/joomla-cms/blob/staging/administrator/language/en-GB/en-GB.ini#L945

Then we proceede like that. My concern is that we have different ways to translate stuff noe despite it would be possible to use the Joomla way only.

@laoneo Pretty please don't do it through Text._(); USE DATA ATTRIBUTES. In fact just copy paste from the link I've pasted above!

i am sorry i reacted like this, but it is very frustrating to start some work, mobilising a lot of people and then, suddenly, see this go down the drain. Evidently, going through .ini strings would have been easier, but we also provide specific js lang files for tiny mce, therefore we are used to this process.

My concern is that we have different ways to translate stuff noe despite it would be possible to use the Joomla way only.

We already have translations in JS files at least in TinyMCE. So it is not a new process for our translators.
Also I think it's quite common practice for JS script to have translations done like this.

@laoneo @infograf768 @Bakual so let me give some reasons why get those as sj files instead of ini:

• we needed a way to ship the new calendar in working condition (if ini was used, chances where that till someone updated their respected languages the calendar will be broken)
• we ship the files without wasting computational power (ini have to be parsed, assigned to an array and then manipulated and served as inline js or data attributes)
• override IS possible for anyone by overriding the jlaout of the field + some logic for the overrided js file (e.g. check lang ad serve a different version of the file)

The only bad thing in this approach is that someone cannot override a day name in the ini file and expect that to be reflected in the calendar.

I hope, this clears somehow the decision to go with a js file instead of the current ini approach

IMO having translations in js files should only be done when there is absolutely no other way, eg. we are using an external lib. Especially when we have some of the translations already available in the ini files, we should use them.
I mean every calendar widget I know has a way to pass translations strings as options (@dgt41 never saw it trough data attributes). But if the maintainers do agree on that approach, then we let the stream flow.

I mean every calendar widget I know has a way to pass translatiin strings as options (@dgt41 never saw it trough data attributes)

Data attributes is the only way to get different strings per instance. Otherwise we have to revert to inline initialisation of the calendar (so to pass translation strings as options) but then we will fail again on repeatable forms...

data-attributes are ugly for such cases. The JS file is fine.