Hi *, On Tue, Jan 29, 2013 at 1:02 PM, Erich Christian <[email protected]> wrote: > Am 29.01.2013 10:38, schrieb Florian Effenberger: >> Niklas Johansson wrote on 2013-01-28 20:19: >>> To be honest I still don't know where to translate what. I redid the >>> changes in sv_SE.php-file >>> (attached). In github it should replace this file: >>> https://github.com/tdf/cms-code/blob/master/mysite/lang/sv_SE.php >>> >>> I hope I did not mess up row 15: >>> >>> $lang['sv_SE']['Navigation']['TOTOP'] ='? till toppen'; >> >> the way our website interacts with git is unfortunately one of the >> major obstacles for me, being totally undocumented.
github repository is the base for the live site. It is not always 100% in sync with what is on the production site since changes are done on the production site when needed and then some time later synced with the github repository. (and of course production site has the site-specific configuration files and real secret keys) >> Erich, do you have more insight here, where to change what in git and >> where to push/pull? > > Ok, here is my afaik "insight": > > Either you have a local checkout of the repository or use the > webinterface to apply changes directly to the respective files. wsadmin > may also use git bash at kermit but I didn't do that yet. Nah, that is not really suitable for people not part of the repository's access group. Basically this is what happens: Someone wants to creates bigger change → that person tests and develops that stuff locally/on a staging server. When done, depending on personal preference either a pull-request is created (when that person used github as well), or a (github) issue with a patch is created, or a mail to the website list with a pointer to the files is sent. Small changes, either because it was mentioned in mailinglist or on irc → an admin usually does that small change directly on the live server, and then sometime later pushes it with some other changes that did accumulate. (not perfect in terms of how it should be, but well...). If that change is a pull request on github, then it first gets integrated into the github repo (since that's just one button-press) and then the production repo gets updated with the change from the github-repo. But you only need to remember that github is the basis for the production site, but production site has additional configuration (database configuration, etc). Now that is for code/template changes. For translations pootle is used, so there's an aditional instance to take into account. > Translations of the DownloadSimplePage don't need to prove anything, so > it looks like Rimas just committed all the changes he was aware of. Rimas exports the translations from pootle and creates a corresponding pull-request/provides a patch that I (or someone else) will then integrate into the github repository. The production site is then updated with the github repo. Manually changes/fixes bypassing pootle are possible (send a patch/mail the error and the desired replacement to the list) - those will then also be applied. But of course if you don't do the same changes in pootle as well, the next time Rimas does export the files the fixes will be lost again, as I just take whatever pootle delivers and assume that those are the current/desired translation strings. ################################################ As this was about translations via the lang.php files: * the main source is pootle * but since pootle roundtrip is sometimes slow, changes can be applied manually * manual changes will likely be overriden on the next pootle roundtrip if those changes were not done to the corresponding strings in pootle. ciao Christian -- Unsubscribe instructions: E-mail to [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/website/ All messages sent to this list will be publicly archived and cannot be deleted
