Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | l10n/localization links are broken | ||
---|---|---|---|
Product: | Infrastructure | Reporter: | Martin Hollmichel <nesshof> |
Component: | Upgrade | Assignee: | Unknown <non-migrated> |
Status: | CLOSED FIXED | QA Contact: | issues@www <issues> |
Severity: | Trivial | ||
Priority: | P2 | CC: | Dieter.Loeschky, issues, lsuarezpotts, nils.fuhrmann, stx123 |
Version: | current | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
Martin Hollmichel
2001-08-04 17:02:25 UTC
There is no functionality problem, so there is something different about the content of this index.html. Louis and I discussed this and it is possible the project owner has some improper code on his home page. I will look further into it. Downgrading this to a P2 defect. P1s should be reserved for defective functionality which prevents the team from using the site for its main purpose - not that this isn't a serious problem, but we will need to prioritize. if I check in l10n/www/index.html it will be displayed, but unfortunatly the tigris content were (and are) checked in L10N/www/.... The project owner will need to commit his content to the correct (lower-case) CVS module. No. Recommit is not the solution, on tigris the l10n project has matched the /cvs/L10N tree and we expect that this is the case after migration, too. 1. We don't want to loose revision history on /cvs/L10N/www files. 2. We also want to have access to /cvs/L10N/<modules> via l10n.openoffice.org/source/browse/... . this is now empty, too. Moving from /cvs/L10N to /cvs/l10n is no possible solution for us, because then older workspaces won't work anymore. SourceCast defaults all directories to lower-case for consistency's sake. This was a design decision to make the app more forgiving of user inconsistency in naming conventions. However, it obviously doesn't function well with legacy upper- case directory data. There are two ways to fix this. The first is a quick patch that will link l10n and L10N, and that has a potential to cause bugs elsewhere in the application. The second fix is not difficult, but it requires some effort on both of our parts to solve the issue permanently. Ops will run the following script, which will take care of the problem with regards to the application itself and CVS: cd /cvs rm -f -r l10n configuration mv L10N l10n mv Configuration configuration cd /usr/local/tigris/data/helm/htdoc/ for i in configuration l10n ; do (cd $i/www ; HOME=~tigrisc setuidgid tigrisc cvs update) done rm -fr L10N You guys will run the following (after making backups, or course) wherever workspace will be affected by the directory-name change: cd $workspace bash for i in `find . -type d -name CVS` ; do perl -pi -e 's/L10N/l10n/' $i/Repository perl -pi -e 's/^Configuration/configuration/' $i/Repository done exit If this is an acceptable fix, I can get the wheels turning this week. I prefer the solution to link l10n with L10N To be more specific: I would prefer ln -s L10n l10n If you decide to move the currect L10N data to l10n, don't forget to adjust the aliases in the modules file. i18n L10N/i18n i18n_simple L10N/i18n i18npool L10N/i18npool DL: Please fix this issue immediately because we would like to update the page with new infos. Therefor I've changed the priority to P1. We are preparing to stage this fix prior to production. I'm hopeful that it will be ready to go on Monday - but if we run into unforeseen problems, may I recommend that you put up a 'temporary' index.html page in l10n (lower-case)? When we do the switch, your temporary page will get lost and it will need to get reloaded, but this is a very quick operation. Complete. This is what we did: 519 cd /cvs/ 520 rm -rf l10n/ 521 mv L10N l10n 523 cd /usr/local/tigris/data/helm/htdoc/ 527 rm l10n/www/index.html 528 cd l10n/www/ 530 HOME=~tigrisc setuidgid tigrisc cvs update ..made sure http://l10n.openoffice.org/ looked ok in the browser 533 cd ../.. 538 tar cf L10N.tar L10N/ 539 mv L10N.tar /var/ops/ 540 rm -rf L10N/ Folks will now need to make sure that their work references l10n rather than L10N. People can run the script referenced in this issue if they wish. The project owner should post this info on the project home page. Hi Kat, to cite my comment from 8/10
> If you decide to move the currect L10N data to l10n, don't forget to
> adjust the aliases in the modules file.
These have to be lowercase now:
i18n l10n/i18n
i18n_simple l10n/i18n
i18npool l10n/i18npool
Do we really need another issue for that?
Almost complete: The requested URL /local-access-only/l10n/www/localization/Translation_Tips.html was not found on this server. Links from the home page to documents in the subdirectory www/localization don't workj. Either a clean checkout (instead of update) or correction of rewriting/redirection may help. *** Issue 1432 has been marked as a duplicate of this issue. *** Kat, please update the CVS modules file to reflect the new lowercase name of l10n. Complete. Modules file now contains i18n l10n/i18n i18n_simple l10n/i18n i18npool l10n/i18npool It's still not possible to do an checkout i18n. even worse, I'm not allowed anymore to do an checkout of CVSROOT. don't forget to change the L10N/transex3 module as well (as far as I remember, I don't see the CVSROOT/modules file anymore) OK, something's obviously wrong. Meantime, it is possible for folks to get their work done if they type the full directory in CVS command line (I was able to check out l10n/i18n, for example). Will update the issue shortly. Jeff, for us here in Hamburg, it's possible to live one more day with this issue. But for the upcoming OOo638 release it's essential that this alias works (we want to upload 638 files tomorrow, Wednesday). Oh, I forgot, Wednesday, european time ;). OK, modules file has been fixed properly. Successfully did cvs co of all aliased modules for l10n/* I still get the message "The requested URL /local-access- only/l10n/www/localization/OpenOffice_Glossary.html was not found on this server." for the subdirectory. So if the modules stuff gets fixed, please don't close this issue before not fixeing the localization path. ahhh, wonderful the cvs co stuff is working now. I will now open a can of beer to celebrate this, but the localization directory is still not accessable. Changing summary (as it's now a broken link problem rather than a CVS situation) and priority. Martin, I see what you're talking about now. verified aliases ok. I don't know who did what to resolve to problems with the www/localization directory. But it works without recommiting now. verified ok DL: closed |