[#124] - g11n
- Closed
- 2 Nov 2013
- Medium
- Build: framework
- # 124
- Diff
- elkuku:g11n
- Success default The Travis CI build passed Details
User tests: Successful: Unsuccessful:
There is currently an open issue where @mbabker points out the reasons why it might be good to have the JTracker application available in multiple languages.
I would agree with that completely.
Currently there have been responsible programmers creating about 50 language keys for the JTracker application (about a dozen of them being used) and we also have the "core CMS" language files containing houndreds of strings, not used anywhere.
The rest of the strings used in the application has been hard coded by a group of irresponsible developers (including the one opening this PR...). The reason why ?? I can only speak for myself: I was too lazy ;(
So - I think we have several options to go from here:
1) The J!Tracker remains "english only"
Nothing to do. This issue (and #73) can be closed.
2) Use ini files and ALL_CAPS_LANGUAGE_KEYS
Wait until somebody converts all those hard coded strings to ALL_CAPS_KEYS and spend some lazy evenigs on the creation and maintainance of the language files.
We might wait for that to happen.... or
3) Go crazy...
I might have stated before that I'm a very lazy person. So I like to spend my time creating scripts that do the "ugly work" for me. - Like the creation and maintainance of language files :P
The proposed solution to the above mentioned problem implemnents a (still) experimental language handler, that has not been tested out there in the wild.
The basic idea is:
- Read language files in multiple formats.
- Extract the key/value pairs.
- Store the result in a "permanent cache" to speed things up.
The language file format to use in JTracker will be po (gettext), the result is stored to a "native PHP array" which is written to a text file. Other options can be explored.
3a) Required changes
Changes to hard coded strings in Twig templates and PHP code:
// template.twig
<label>
My String
// change to:
{{ translate("My String") }}
// **OR** just use a pipe and a shortcut:
{{ "My String"|_ }}
</label>In PHP you would use the global function with an easy to remember name; g11n3t (*)
echo g11n3t('My String');... and go home !
(_) _btw*: g11n3t means globalizationtext. If you don't like it, you may create your own alias ;)
The next step would be the creation of the language files.
3b) Language template creation
For gettext files, you first create a template that contains all the keys and empty values.
These templates are used to create and update the localized language files.
The file extension for template files is .pot.
# Extension.pot
msgid "My String"
msgstr ""
These files can be created and maintained manually, however... I'm a lazy person (did I say that before ? )
The gettext utility xgettext can read a wide range of code languages and supports a custom function name.
It supports over 20 languages officially, others just "work" (like JavaScript can be parsed as Python...) but the only unsupported language I know is Twig :(
Fortunately this is a known issues, so the solution is to compile the templates and then run xgettext over the generated PHP code.
There is a new script that just collects all relevant files and passes them, along with some options, to xgettext:
tracker.php make langtemplates
Will automatically generate the language templates for the core JTracker application, the JTracker template as well as all the Apps.
Those language templates, once created, are now ready to hand over to the translators or send them to an online translation service (e.g. transifex).
Job finished :)
3c) Localize It !
To actually "see" the site in different languages, you have to create a file that contains the localized strings for every language.
The extension for language files is .po.
For example a german language file might look like this:
# de-DE.Extension.po
msgid "My String"
msgstr "Meine Zeichenkette"
A chinese language file might look like this (google says..):
# zh-CN.Extension.po
msgid "My String"
msgstr "我的字符串"
and so on...
Translators may notice here, that you always see the original in clear text above the translation. -- If you plan to handle the translations manually...
While you can also create those files manually, the gettext tools msginit and msgmerge can create and update language files from a given template - So why not use them (remember: me lazy...)
tracker.php make langfiles
will create language files for the core, the template and all extensions (Apps) in all defined languages.
What else ?
System requirements
To manually create and manage your language file(s) you will need:
- Your hand(s).
To have your language files created and managed automatically you will need:
- gnu gettext - from which you will only need it's utilities.
The gettext utilities should be available or installable on all *nix based systems, as well as some sons/daugthers and parents (like BSDs and apple stuff).
If you are stuck on windows, your best bet may be cygwin (as always). There is also MinGW, a sourceforge project, as well as this site.
I have not tried any of the above currently beside my own linux box, but I believe that if would be no problem for a windows developer with decent skills to modify the script ;)
Known issues
- There is one big FAT issue currently: Internally all strings are contained in a single array. Meaning that you can not translate the same key in two different ways in the same page call.
I believe that our application is "small enough", so this wont really be an issue.
There is a solution deep down in my head, but it hasn't been translated to code yet ;) WIP - Pluralization is supported but not implemented yet. WIP
- JavaScript translations and pluralizations are supported but not implemented yet. WIP
- Performance... This will be the last time that I mention that I'm lazy but... to avoid ugly escaping/unescaping of quotes, I simply base64 encode and decode the string and md5 encode the key which is, I admit that, very very time consuming W-I-P...
Refs
- https://github.com/elkuku/g11n - The experimental language handler oO
Demo: If you want to see this in action there is a staging instance which is currently running with full debug enabled here (link will change)
P.S.: I tried to keep this post short but seems like I failed miserably... sorry for the long post and thanks if you made it that far =;)
P.P.S.: I just realized, that this PR also contains commits from #123, so it should be clearer after that is merged ;)
Yes.
I don't know what the server supports where the site is currently running. But I can imagine a fully automated language template file generation, upload (to Transifex) and language file download (from Transifex).
On po vs. ini files... I would have a long list why po files IMHO are the better choice for holding internationalized strings, but I can also understand JM when it comes to change old (and working) habits.
From my POV using a script to create and maintain language files and using a "more appropriate" format would be a win for all involved parties ;)
Personally I did not face .po files (as far as I remember WP uses them), so thank you Nikolai for so extended intro :) If know issues are not so big problem I did not mind to try this.
And I'd like to add a screen shot of my favorite off line translation tool. I use the german version, but the screen shot on their website happens to be in french (some pun intended ;) )
http://userbase.kde.org/Lokalize
cool eh ?
What the screen shot does not show:
Those po files also support the annotation of the file / line where the string is defined in the source code. So you can just click and jump from the translation program, or from you favorite IDE, from the language file to the source code file.
Of course, the annotation is automatically added when generating the language files.
Example
# ru-RU.JTracker.po
#: /src/JTracker/Pagination/TrackerPagination.php:201
#: /src/JTracker/Pagination/TrackerPagination.php:206
msgid "Last"
msgstr "прошлый"
PhpStorm
" Using .po files, I doubt many of the "core translation teams" would be willing to do translation work here (JM has a hard enough time getting some of them to update every two months as it is), and with Transifex, we can tap into the community to help with that."
Many of the 'official core' translators already use Transifex. Perhaps it would be good to remember that OpenTranslators has well over 1300 Joomla extension translators made up of professional translators, joomla core translators and users.
We would help - just ask :)
Heh, look at that - seems that the question "who will do the translation work" has been cleared - welcome on board @Hils ;)
I am sure we are going to ask very soon for your help - seems like @mbabker isn't all against the idea to have Transifex getting involved :)
Now, apart from the language file format to use (po is just an option) and who is doing the work ;)... the question that really needs an "OK" is the method being used to process the whole language stuff from the "technical side" - that is:
- The parsing of the files (po, ini, etc.)
- The storage method for the result (currently PHP arrays in files)
- The translation process at run time (regarding performance and name spacing).
Is the current state working for the project and does it make sense at all ?
Not against it at all. I've had my own extensions on Transifex since day one of OT. What I was saying is that I'm pretty sure we'll get a better response through OT than going through JM, I just want to be sure it won't be difficult on them to do.
Things are getting clearer ;) Transifex (and OT) supports po files just fine - as an added bonus, all persons involved in translations are being added to the translation files by transifex - this is standard gettext behaviour.
So we can read this information and display some "credits" page with the names of the translators - everybody likes that I guess ;)
I just added a phpinfo() view (built the same way the CMS wraps it in the template for the system info) and pushed that onto i.j.o, so @elkuku you'll be able to get all the server side info you need.
Sorry, correction... I just realized that it runs good on i.j.o.... could you verify that it still works ? ;)
Admittedly, the first time I had set the file names, I was running into issues and used PhpStorm to rename them. Guess the filesystem didn't like that 
Updated, good to go.
While I'm thinking about it, I've got a half written PHP wrapper for the Transifex API (it hasn't been touched in a year, I have no clue how usable it is today). If that for whatever reason ends up being usable here, I'll put the leg work into finishing that sucker and getting the changes needed into the Framework HTTP transports (which, I'd have to look at my own commit history to figure out WTF I needed to change and why).
Actually I was looking at their API docu yesterday ;)
Your wrappers look nice, just like the GitHub API for the old platform :) - would be cool to bring it in, use it, and push it up to the framework ;)
How to avoid those merge commits ? I know about the --rebase option but it had caused me a lot of headache in the past, so I try to avoid it ;) - I hope that's not a biggie...
From my point of view if Drupal uses po without a problem why we can not start to use it also? Are technical aspects is something stoppable at the moment?
How to avoid those merge commits ?
That's I was asking also :) Not that I hate this merge commits, but... As far as I know rebase will squash your commits into one and you will not get the commits history. I found this article which explains how to avoid this (comments are also useful). And this article is also good one (understanding merge vs rebase).
BTW @elkuku I see you are working also with the RU translations. Do you know this language well? It's my native :)
I think Drupal uses gettext naively (not sure), which would mean some server side requirements, while I am proposing a "native PHP approach".
Thanks for the links on rebasing, very informative.
As Linus explains:
So rebasing and cleanups may indeed result in a "simpler" history, but it only look that way if you then ignore all the other "simpler" histories. So anybody who rebases basically creates not just one simple history, but
a many "simple" histories, and in doing so actually creates a potentially much bigger mess than he started out with!
I think I'm done with rebasing :P
I think if you are merging with conflicts, the merge commit should be preserved.
I also noticed that pulling without conflicts does not create merge commits - sometimes...
ru-RU: Despite my name I have to confess that I don't know anything about the Russian language ;)
In the past, when testing multilingual stuff, I always picked a language with non latin characters to, well... see at a glance whats being translated...
I normally pick chinese, but I chose russion this time, thinking that maybe somebody in the project knows this language and may be interested in translations (big 
)
Two things about Drupal's translations.
First, they use po files to a certain extent but they have customized this
approach significantly and use database support, too. Like most, they have
found the .po approach to be very slow.
Second, from what I understand, Drupal is planning to move to Symfony's
Translation approach. In part, this decision was sort of forced on them
when they discovered last November that a component they wanted to use had
added a dependency to the Translation package. As a work around, a patch
was addedhttps://api.drupal.org/api/drupal/core!vendor!symfony!translation!Symfony!Component!Translation!TranslatorInterface.php/interface/TranslatorInterface/8to
isolate the change for v 8. But, if I understand correctly, it will be
fully embraced after v 8 release when there is time to think the
implementation through.
I have not looked very closely at it, but I understand Symfony
Translationshttp://symfony.com/doc/current/book/translation.htmluses
an interface to a Java-based set of files which provide a lot of the
standard localization (i.e., the currency, time, ltr standards, etc.).
On Sun, Jun 30, 2013 at 1:04 AM, Dmitry Rekun notifications@github.comwrote:
From my point of view if Drupal uses po without a problem why we can not
start to use it also? Are technical aspects is something stoppable at the
moment?How to avoid those merge commits ?
That's I was asking also :) Not that I hate this merge commits, but... As
far as I know rebase will squash your commits into one and you will not get
the commits history. I found this articlehttp://viget.com/extend/only-you-can-prevent-git-merge-commitswhich explains how to avoid this (comments are also useful). And this
article http://gitguru.com/2009/02/03/rebase-v-merge-in-git/ is also
good one (understanding merge vs rebase).BTW @elkuku https://github.com/elkuku I see you are working also with
the RU translations. Do you know this language well? It's my native :)—
Reply to this email directly or view it on GitHub#124 (comment)
.
While I'm thinking about it, I've got a half written PHP wrapper for the Transifex API ...
We could create a Thing in our J!TrackerApplication that fetches from Transifex, does " something ", and then pushes the translations "stuff" to the official Joomla! Extension Server™®, the "App Store" or similar institution...
</ThinkingOutLoud>
@AmyStephen
Drupal is a funny beast... I believe the community involvement, people contributing in writing code, their organizational structure and also their documentation... (I'll stop here) are some years ahead of what Joomla! is right now.
But every time I tried to learn something from their code (drush and stuff), I simply couldn't.
In the end I still believe in OOP. Not sure how they handle name spaces and stuff 
I also had a very quick look at Symfony's translation system (from the point of their documentation).
I don't know why, at some point, it always ends in Symphony.... (OK I have an idea, but it's hard to admit..)
From what I can see, if we plan to implement it, we have to include and use the basic Symfony application structure and include it in our code base - not sure about it but I'd like to stay with J! at least for the ""most basic stuff""
Do we want to go ahead and do this for v1 or hold off for v2?
definitely not for v1.
Agree, not for v1
Just a remark here as I saw the post on list:
we had very good reasons to not use .po and choose ini instead for 1.5 and since:
.po files need to go through a not obvious process to be produced and many TTs are just not coders enough to follow up.
Ini files are easy to check and edit in any good utf8 text editor.
@infograf768 1. Sorry for the late reply ;)
we had very good reasons to not use .po and choose ini instead for 1.5 and since:
.po files need to go through a not obvious process to be produced and many TTs are just not coders enough to follow up.
That's true if they are processed the "standard way" - This PR is about a system that handles language files (not just po files) and processes them for use by a PHP script.
Ini files are easy to check and edit in any good utf8 text editor.
I would say that po files are easier since you always have the original and the translation present...
Example: de-DE.Tracker.po
The real advantage for po files here in the JTracker project is the usage of an external program for the creation and maintenance of the language files.
It's stuff for lazy people....
@infograf768 - For this project specifically, we'll most likely shift completely away from using Joomla's language handling in favor of this language implementation. With this code and code I need to one day finish that would give us an automated interface to Transifex, we could outsource translations of this project through OpenTranslators like many of us do with our Joomla CMS extensions. That's a decision we've made for this project specifically and doesn't reflect something we'd do in the CMS. I see some interesting benefits for this tracker with that type of workflow in that our tracker would have a translated interface for our international users and we wouldn't add any additional workload onto the CMS's translation teams to do this as well. With this and my own code implemented, we add a button to an admin only UI or write a cron job and we have translations sync'ed up between the server and remote service quite easily.
Just a small remark: Transifex != Open Translators. To keep it more general and also open for several Joomla Language Teams that do not cooperate with Open Translators it could be good to just mention Transifex and not specifically Open Translators. Probably more people will be interested in it then.
I specifically mentioned OT because the topic of using them has come up previously in this thread.
@HermanPeeren are you really suggesting that changes should be made for
people who will not cooperate with other volunteers?
On Wed, Sep 4, 2013 at 2:43 PM, HermanPeeren notifications@github.comwrote:
Just a small remark: Transifex != Open Translators. To keep it more
general and also open for several Joomla Language Teams that do not
cooperate with Open Translators it could be good to just mention Transifex
and not specifically Open Translators. Probably more people will be
interested in it then.—
Reply to this email directly or view it on GitHub#124 (comment)
.
@Amy no, no changes necessary at all.Everybody agrees the Transifex system gives a lot of interesting possibilities. Some people just don't want to cooperate with the Open Translators group, because at the moment there would not be enough guarantees for the quality control of "official" translations. I don't want to discuss here if those reasons are valid or not, that is another discussion. I just advise to mention the technical system (Transifex) and leave the politics (cooperate with Open Translators or not) out. Then everybody is happy. As I said, just a small remark, not a rant or whatever. Only a way to avoid an unnecessary pain point for some.
BTW I participate in several translation-projects on Transifex, both within and outside Open Translators. I don't care so very much about OT or not, but would prefer a better communication between OT and the "official" Joomla Translation Teams and solve this unproductive problem. If that is not possible now, I would prefer not to unnecessary chose to exclude that group that is opposed to OT.
On 4 September 2013 21:11, HermanPeeren notifications@github.com wrote:
Some people just don't want to cooperate with the Open Translators group,
because at the moment there would not be enough guarantees for the quality
control of "official" translations.
oh Herman - I am sad that you cannot see the advantage of crowd sourcing
translations, especially as the 'crowd' is now over 2050 Joomla volunteers
which include many of the 'official' translators and many professional
translators. Contrast that with some of the official translations in some
languages being controlled by one person. There is no co-operation needed
with OpenTranslators - we are merely a conduit.
Hilary Cheyne
I do see the advantages and I do see the validity in some other arguments (and have my own thoughts about it), and I think, specially as someone who sometimes works with Transifex both within OT and outside, I think WE don't disagree so very much, but I don't want to hitchhike this thead and discuss this here. I ONLY wanted to make a remark that probably more people are enthusiastic if you just mention Transifex and not OT. Had not even seen that it was mentioned earlier in this thread, becaus I (shame-shame) had not read everything here yet but just wanted to place a tiny remark to hold more people aboard. Nothing more, nothing less. And let's have another place for a productive discussion how to solve that silly controverse.
...no we probably don't disagree! But to not mention a joomla community project because it might offend a handful of people doesn't make sense to me!
+HermanPeeren - The funniest part of your comment is that you want to avoid
the politics.
On Wed, Sep 4, 2013 at 3:11 PM, HermanPeeren notifications@github.comwrote:
@Amy https://github.com/Amy no, no changes necessary at all.Everybody
agrees the Transifex system gives a lot of interesting possibilities. Some
people just don't want to cooperate with the Open Translators group,
because at the moment there would not be enough guarantees for the quality
control of "official" translations. I don't want to discuss here if those
reasons are valid or not, that is another discussion. I just advise to
mention the technical system (Transifex) and leave the politics (cooperate
with Open Translators or not) out. Then everybody is happy. As I said, just
a small remark, not a rant or whatever. Only a way to avoid an unnecessary
pain point for some.—
Reply to this email directly or view it on GitHub#124 (comment)
.
It makes sense to me: why offend people if you don't have to? It is unnecessary to limit the use of Transifex to OT. The technical system is Transifex, OT is a group using the Transifex API. I don't want to discuss the validity of the reasons the "offended" have here. You can say it is just "a handful, but they are the leaders of our core translation groups. It would be unnecessary to have them put more energy in the controverse.
You know, I'm from Holland. A flat country. No hills to hide. The former water now is land: "polders". We even have made a verb out of it: "polderen", which means: to seek for compromises, to seek for a common things to live side by side on this small piece of land.
I too live on a polder Herman - in East Anglia, UK ;)
But do you have a verb: "to polder"? ;-)
Well, sorry to have interupted. Was intended as just as a tiny remark, but I should have read the whole thread. Besides that, was the comment on GitHub not primarily meant for code remarks. So: sorry again that I probably mentioned this on the wrong spot. But I do hope we once totally solve this stupid and unproductive "problem". And to contribute to that was my sole intent.
On Wed, Sep 4, 2013 at 3:45 PM, HermanPeeren notifications@github.comwrote:
It makes sense to me: why offend people if you don't have to?
Wish you would have considered that before offending everyone who
volunteers to translate Joomla extensions in Open Translators by suggesting
their name must be removed to avoid offending others.
I am sorry but that is ridiculous. As is your comment about compromise. To
the best of my knowledge, these volunteers are helping. I don't see why
they must be treated like second class citizens.
Done.
I didn't mean to offend anyone. If you felt offended: sorry. It just shows how sensitive it is, on all sides. I have not said nor meant to suggest that the name of Open Translators should be removed. I just wanted to remark, that the technical part is the Transifex API and that is the part we are talking about here on Github. I don't care whether you do the translations on Transifex via Open Translations or not and for a technical discussion it is irrelevant. Personally I don't see much difference between the Transifex-teams I participate in within or outside Open Translators (although I have more experience outside OT, for instance coordinating the Dutch Seblod translation). Let's just make it all better.
+HermanPeeren - sides? Not exactly certain what you mean.
You mean those who have decided to volunteer with Open Translators and
those who have not? If so, that's not a problem. People are free to choose
where to invest limited time.
Do you mean "sides" like those who want their extensions translated free of
charge by some 2,000+ Open Translators, and those who decide they want to
use another option? If so, that's not a problem, either, since developers
should be able to make their own choice.
Or, do you mean "sides" like those who support the volunteer translators
and Joomla developers who freely choose to work together as an Open
Translator effort so that people all over the world can use Joomla and
those who do not support those people?
On Wed, Sep 4, 2013 at 11:48 PM, HermanPeeren notifications@github.comwrote:
I didn't mean to offend anyone. If you felt offended: sorry. It just shows
how sensitive it is, on all sides. I have not said nor meant to suggest
that the name of Open Translators should be removed. I just wanted to
remark, that the technical part is the Transifex API and that is the part
we are talking about here on Github. I don't care whether you do the
translations on Transifex via Open Translations or not and for a technical
discussion it is irrelevant. Personally I don't see much difference between
the Transifex-teams I participate in within or outside Open Translators
(although I have more experience outside OT, for instance managing the
Dutch Seblod translation). Let's just make it all better.—
Reply to this email directly or view it on GitHub#124 (comment)
.
This discussion is not technical relevant.
If you want to discuss Open Translators (of which I'm one of the volunteers), let's find a proper spot for it. I'll be happy to explain what I mean; no need to make up all kinds of strange options of what I would mean. I'm off internet now; back somewhere tomorrow.
Keep it in mind next time you raise the issue, +HermanPeeren.
On Thu, Sep 5, 2013 at 8:52 AM, HermanPeeren notifications@github.comwrote:
This discussion is not technical relevant.
If you want to discuss Open Translators (of which I'm one of the
volunteers), let's find a proper spot for it. I'll be happy to explain what
I mean; no need to make up all kinds of strange options of what I would
mean. I'm off internet now; back somewhere tomorrow.—
Reply to this email directly or view it on GitHub#124 (comment)
.
Given all the interesting comments here, I think we should merge this rather sooner than later
I'd be fine with it. Maybe I'll find the motivation to finish my Transifex wrapper too (and get it namespaced, and work my hacks for the HTTP package back into the Framework... gah, so much to do!)
Updated.
I also added the gettext package to our virtual environment, so creating and updating language files can be done from within the virtual environment, in case a developer can not install gettext on his/her operating system.
It goes like this:
vagrant ssh
cd /vagrant/cli
./tracker.php make langtemplates
./tracker.php make langfiles
It would be nice if a "non-Linux" user could test this
@elkuku I set up virtual environment successfully. Some fixes was just pushed. But I have a problem:
vagrant@debian-70rc1-x64-vbox4210:~$ cd /vagrant/cli
vagrant@debian-70rc1-x64-vbox4210:/vagrant/cli$ ./tracker.php make langtemplates
: No such file or directory
vagrant@debian-70rc1-x64-vbox4210:/vagrant/cli$
As far as I understand I should use your branch to test it?
Yes, ... not sure why but it seems that the php5-cli package has been moved to a separate package in Debian stable... nobody's perfect
Please retest ;) NOTE: I think you should use vagrant destroy and then vagrant up when "larger change to the code base happened"....
And yes, you have to use the elkuku/g11n branch to test this properly - I think it would be better to move it to the main repo.. ?
Would be great if you move it :)
Hmmm now this is interesting...
I have no idea how and why GitHub associates the newly created branch to the PR but it seems really brilliant :)
Could someone push a commit to see if it really get's included in the PR ?
Commit isn't showing here but it's on the branch. Weird.
So it looks more like a bug than a feature ;)
I'll merge it then ;)
Another feature hidden in this branch is a new debug toolbar:
The orange "2" means two untranslated strings :)
I was originally thinking about something like this for the CMS, but it seems much more easy to implement here...
Anything's easier to implement here than in the CMS 
@elkuku I have reinstalled using your branch, but still 'No such file or directory' comes up. But it worked using php:
php tracker.php
But now I have another issue:
vagrant@debian-70rc1-x64-vbox4210:/vagrant/cli$ php tracker.php install
ERROR: Configuration file does not exist or is unreadable.
#0 /vagrant/cli/CliApp/Application/CliApplication.php(95): JTracker\Service\Conf
igurationProvider->__construct(Object(Joomla\Registry\Registry))
#1 /vagrant/cli/tracker.php(30): CliApp\Application\CliApplication->__construct(
)
Digging into it I found out that getenv('JTRACKER_ENVIRONMENT') returns vagrant" - with double quotes at the end. That's wired... I did not find why :(
Hmmm, this looks odd :(
Could you verify some things:
- I think the box isn't yet ready for VirtualBox 4.3 - please use VirtualBox 4.2
- Can you open http://127.0.0.1:2345 successfully ? (a database error is expected)
- You did a
vagrant destroyfollowed by avagrant up? - You checked out the latest commit from the branch ? .... ;)
Today I played with pluralization using Russian language files - looking good ;)
Yeap I checked out the latest commit from the branch, http://127.0.0.1:2345 is ok and I did vagrant destroy followed by a vagrant up. Today I will try VB 4.2 and will see.
Today I will try VB 4.2 and will see.
So you had previously VB 4.3 ? Not sure if that could be the cause. The errors you get are really strange, including the environment var with the quote... So the script is in fact looking for a config file including a quote ?
Yeap I am running it on 4.3. I am also think that this is not the cause, but still will try on 4.2 ;) Indeed it is strange and I did google for it, but nothing :( And yes in the if statement $type with a double quotes... If the same will be on 4.2 then it will be time for us to ask this question on the Stack Overflow
this is not the cause
Actually it wouldn't surprise me that much, knowing Oracle.... I heard about some nasty bugs in 4.3..
The version of the guest additions that comes with the box should also match the major version - That's what I learned today ;)
Another Question: When you read the env var from the CLI, do the quotes also appear ?
vagrant@debian-70rc1-x64-vbox4210:~$ echo $JTRACKER_ENVIRONMENT
vagrant
4.2.18 installed, but it does not help :(
vagrant@debian-70rc1-x64-vbox4210:~$ echo $JTRACKER_ENVIRONMENT
vagrant"
vagrant@debian-70rc1-x64-vbox4210:~$
hmm, while it shouldn't be necessary.. could you just remove the quotes ? :P
vagrant@debian-70rc1-x64-vbox4210:~$ sudo nano /etc/environment
After that you have to logout
vagrant@debian-70rc1-x64-vbox4210:~$ exit
and vagrant ssh again to reload the env vars - thanks for your patience, seems that it takes more than 5min ;)
Ok, now it works, but again
ERROR: Configuration file does not exist or is unreadable.
I did var_dump($file); and got interesting result:
string(33) "/vagrant/etc/config.vagrant\r.json"
CR is breaking all the things :)
BTW I am working on the 4.3 now
That looks like the getenv() call should be wrapped in a trim() call - what is going on here ??
And why can you access the "site" - both use the same service provider...
Wen you access the site with your var_dump($file); in place - what do you get ?
Yeap both use the same service provider. Well I did $type = trim(getenv('JTRACKER_ENVIRONMENT')); and now it works! At last 
php tracker.php make langtemplates
php tracker.php make langfiles
Made templates and updated language files. All this staff is inside g11n dir?
Woohoo amazing
Yes, the template files are recreated with the current date/time. Language files only when the template changes.
The files are created for the core, the template and all the Apps, in their g11n sub directory.
Really glad that we got this sorted out - as you are now able to check if the russian pluralization really works -- as I have no idea - If you have any questions about it - feel free to ask.
Oh - also note that whenever you change the language files, you have to manually clean the cache (!)
This can be done manually, or by a command from the site menu (committed today)
I am glad that we made it :) Will you push changes?
export JTRACKER_ENVIRONMENT=vagrant
And also
$type = trim(getenv('JTRACKER_ENVIRONMENT'));
I am goind to sleep now :)
Interesting note here - when I run vagrant up Apache does not start. I have to do vagrant ssh, then start it with a sudo service apache2 start and site goes up. Sad I forgot to check is a myslqd service running or not, but if after apache start site goes up it looks like a mysql service is starting during vm boot.
But after vagrant destroy and vagrant up everything works as expected. I think that is because during first vagrant up it runs a provisioner and then not.
I wonder how we managed to kill the server :(
I can confirm, that after a vagrant halt and vagrant up the apache service is not running.
If you instead do a vagrant suspend and vagrant up this does not happen...
Also seems that "something" is deleting the log files.
Do you think some code is the problem? It can't be :) And I was trying also with the old setup - env var with double quotes, result is the same. BTW this happens on two different machines: I have a notebook running W7 with the VB4.2.18 and a desktop running W8.1 with the VB4.3.
Status check, since I've been neck deep in CMS stuff the last week and a half (and ironically, the only JWC session I'm (now only mostly) ready for is this project). If this is ready to go, someone scream so and I'll get it in.
If this is ready to go, someone scream so and I'll get it in.
so
-
Bye Joomla Languages... LOL
Awesome
Not knowing anything about the .po files, these would be uploadable to Transifex as they're generated, right? Using .po files, I doubt many of the "core translation teams" would be willing to do translation work here (JM has a hard enough time getting some of them to update every two months as it is), and with Transifex, we can tap into the community to help with that.