When trying to use the language tool in ver. 2.65.2 from PHPLaunch, access
are inhibited and only this errorscreen is produced:
The errorscreen say:"Please close this window and do a login in the former window first..."
Needless to say that I actually are logged in, and needles to say that the former window wasn't a login window.
When trying again to edit the text, the errorscreen doesn't appear, instead an errormessage box flashes up and complaint about a scripterror.
Conclusion: The Language tool can't be used in PHPLaunch - what a shame, because PHPLaunch works much faster than my webhost.
- - - - - - - - - - - - - - - - - - - -
When using the language tool in ver. 2.65.2 from the web or elsewhere, this
problem show up in the help_text.da.php:
The problem is the "empty message"
When the text is translated, the translated text doesn't appear in the previously empty box, instead the untranslated text appear here, and the translated text has disappeared:
- - - - - - - - - - - - - - - - - - - - -
In the English text in $pgv_lang["relationship_id_help"] a certain link, "Relation to me" is mentioned. I'm sorry but apparently I'm unable to locate the "Relation to me" link, making it har to make a correct translation.
As for 3.: this is located on the individual screen, in the box on the right side of the screen. Clicking it jumps to the relationship chart, where the relation between that person and you is shown.
As to the problem mentioned in 2.
When looking at help_text.da.php it appears that the translation isn't wasted after all. It's just sort of attached to the previous text - only that the variable and the initial quote is missing.
$pgv_lang["relationship_help"] = "<b>SLGTSRELATIONSSIDE</b><br /><br />Med denne funktion kan du f vist to personers slgtsrelation.<br />Dette betyder ikke, at de pgldende personer behver at vre beslgtet i lige (blod) linje.<br />Enhver slgtsrelation kan findes.";
<b>SLGTSRELATIONSSIDE</b><br /><br />Hvis du er havnet her via et link p en anden side (f.eks. ved at klikke p linket \"Mine slgtsrelationer\", vil du her se slgtsrelationen mellem disse to personer.<br />I modsat fald er du ndt til at indtaste ID p de pgl. to personer, hvis slgtsrelation du nsker undersgt.<br />Hvis du ikke kender de pgl. personers ID, kan du istedet finde dem ved at klikke p linket \"Find ID\"";
When looking into a fresh (untranslated) help_text.da.php the problem appeared to be even more confusing:
$pgv_lang["relationship_help"] = "Med denne funktion kan du f vist to personers slgtsrelation.<br />Dette betyder ikke, at de pgldende personer behver at vre beslgtet i lige (blod) linje.<br />Enhver slgtsrelation kan findes.";
$pgv_lang["relationship_id_help"] = ""; //See index page
$pgv_lang["next_path_help"] = "Ved at klikke p denne knap, kan du f vist en anden forbindelse mellen to personer.<br />Den tidligere viste forbindelse kan genfremkaldes ved at klikke p linket med den pgldende forbindelses nummer.";
Obviously the line:
$pgv_lang["relationship_id_help"] = ""; //See index page
When I tried to correct help_text.da.php manually, the problem appeared to be even much more confusing:
Because now the problem with the "empty message" warning reappeared.
When I now read help_text.da.php into the XEMacs editor, the syntax coloring revealed a syntax error, only that in my eyes, no obvious syntax errors was present ;-(
At this point, and in utter desperation I now placed the cursor after each line and pressed enter, in order to enter new line breaks - and that did the trick. Once the new linebreaks was entered, the lines - one by one - now appeared to have a proper syntax, and once the help_text.da.php was moved back to the server, the language tool appeared to work without problems.
I guess that the problem described here, is one of the strange problems I and my fellow translators has complained about before!
However, when the problem was present, it sort of took me by surprise, that it was warning about the line being empty in lang.da.php when I was working with help_text.da.php - we probably have yet another problem here:
Thanks for the help :-)
Unfortunately I was using the Xenea Theme, which apparently (to my knowledge) are missing a link to myIndi, and that explains why I couldn't find the text.
When I changed to the Standard Theme I found the link to myIndi in myGedView, and like you said, the link and the text was found in the box in myIndy.
As to the other problems I guess that this was a few of the probs I previously was unable to describe :-)
I have problems with the sedish chars. When enter a swedish char in the message and then saving the Message. the char is being shown wrongly and whne locking in the lang file the char is in ansi format not in utf-8. I havn't filed a bug report on this as it seems that not everybody can recreate the problem.
which one of the swedish language files???
Well I think it is a problem for all files. But is was the lang file tried but the problem is the same in the description field of the gedcom configuration. Roland hade problems with the new sorting alphabets in the login lockout problem. Can this be related to the problem? That is just a thougt not tested.
I can't tell what is causing your swedish characters to be in ANSI, but I can name a few problems which can happen in connection with editing the language files in an external text editor.
When I edit a language file using Notepad or TextPad or similar texteditors on a Windows platform, the texteditors add three "invisible" bytes at the start of the language file. This is done to indicate that the charset used is UTF-8, but since these three bytes are disturbing PHP, I afterwards read the language files into another editor like XEmacs, Crimson Editor or WebWriter (Danish product), where I can see and strip off the "invisible" bytes.
When using this method, I make sure that the Danish characters are in UTF-8, and at the same time I make sure that the infamous three bytes are stripped off and can't disturb the PHP.
Next time I read such a language file into an editor, it need to be Notepad or TextPad or a similar texteditor, because even though that the three infamous bytes are stripped off, Notepad and TextPad are able to automatically recognize that UTF-8 is used - so, when I enter new translations or changes anything, it automatically will be saved in UTF-8. And then I just have to read the file into another editor like XEmacs, Crimson Editor or WebWriter afterwards, where I can see and strip off the three "invisible" bytes.
When I sometimes read such a file into an editor like XEmacs, it will not be recognized that the charset used is UTF-8, and if I under such a condition enter any Danish characters, these newly added Danish characters will be in ANSI (and look like Chinese when viewed in phpGedView) while all the "old" Danish characters will still be in UTF-8.
Now, in order to avoid problems with mixed charsets I therefore uses Notepad or TextPad for editing and XEmacs for stripping off the offending three "invisible" bytes from the files.
Thanks that is help full to know. But I have this problem when saving inside PGV. Even when saving and writing the description string for the gedcom with a swedish char, It gets that problem and ending up locking like a chinese char in descriptive name.
Where can I find texts for "About PhpGedView", "sec" for the bottom statistics and "Browse ..."?
I try to continue with the Hebrew translations.
The "sec. " is hardcoded in functions_mysql.php and functions_index.php. If you want to translate that, perhaps one of the developers can transform it into a variable.
The "About PHPGedView" can be changed in the GEDCOM-settings, Main website text.
I can't find the "Browse ..." anywhere. Can you explain on which screen that is located?
If you are refering to the link on the top section of the alpha site that I set up, it is from the gedcom config file.
Admin> manage gedcoms > edit >
then just change the text. Since this can be any text you want there is now way to have it translated.
If I misunderstood your question, please let me know what you are refering to.
I found the "Browse ..." button in the Upload Media Files.
The texts are from 2.65.1.
How far are you with the translation?
I think the same applies for "browse" as for "sec.". It's certainly not a variable which can be set in a languagefile, I guess the text is part of a standard function, and the language may be only influenced by the language setting of the OS or browser.
If you wish, you can post an RFE for adding both texts in the languagefiles.
I have non final Hebrew texts on most of the screens (the long texts are still missing).
Need to verify in some way all the texts.
I might still detect some additional variables.
Do you guys have a way to pickup the "sec." and the "Browse" values from the OS by using the computer Locale? In that case we do not perhaps need them in the languagefiles, although I normally prefer to use English screens with my default Hebrew computer and Hebrew, English, Finnish, Swedish etc. data.
We can add the "sec" text to the language files.
But the "Browse" button is automatically created by the Browser when using the <input type="file"> field for uploading files. I'm not sure if there is a way to change it or not.
I also miss text file entries on ver 3 alpha for
i. Import GEDCOM files
1. Convert Dates page
2. Bytes read
ii. replace in GEDCOM changes (by edit/delete)
iii. translation of the theme names
Why is the steps text 1/4, 2/4, 3/4, 4/4 but 5/5?
I guess the English is written in USA English.
Have detected some typing mistakes in the English texts. Does the team have any technical writer who could suggest corrections?
I have written some random findings from V.3 below:
a. In other_records Why Other records that link to source and not Records that ?
b. Typo/Spelling mistakes in English text Configure Help EN
It will list you the the
This module wil compare
Descendency instead of Descendancy
This codes enables semikolon
c. Typo/Spelling mistakes in English text Language EN
user their account
to your site edit the
has been error
administrator we speak of technical support
vii. pls_note05 & register_info_01
Webmaster only mentioned in help text site speaks of technical help or support contact.
add an Individual by their ID number (several similar labels)
the person to determine if they are
allows you to taking
I would write e-mail, GEDCOM, PhpGedCom (even the icon is different) etc. always the same way on the site.
Yes, you are right. It's a problem for all languages to keep the expressions consistent with eachother. Up to now, each translator uses his own "expression-list", which is ok I think. By having one main translator for each language the consistancy is guarded.
Perhaps it's a bit more difficult for the English language, because (by my knowledge) each developer adds the text for what he added/changed himself.
Thinking it over, it wouldn't be bad to have a main translator for English to.....
What do you all think about that??????
If I should answer I would say: Good idea :-)
It is not clear to my why I should create or not create GENDEX files.
The relevant Help text should be more clear.
The gendex files are only needed when you want to have them indexed by the gendex-site. There you have to indicate the link to your gendex-file. If you don't link-up with gendex.com, you don't need them. See also http://sourceforge.net/tracker/index.php?func=detail&aid=893243&group_id=55456&atid=477082
I agree with you that the text could be more clear about this......
I agree that also the English text must be consistant.
Where can I find on the site links to the the following Help messages?
GEDCOM Edit Utility $pgv_lang["show_changes_help"]
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.