PhpGedView

Why is it, that lang.da.php, lang.es-ar.php and lang.fr.php are the only language files which contains the following privacy related translations:

$pgv_lang["edit_privacy"] = "Konfigurering af privacy.php";
$pgv_lang["PRIV_PUBLIC"] = "adgang for enhver";
$pgv_lang["PRIV_USER"] = "Kun adgang for autoriserede brugere";
$pgv_lang["PRIV_NONE"] = "kun tilgængelig for administrative brugere";
$pgv_lang["save_changed_settings"] = "Gem ændrede indstillinger";
$pgv_lang["add_new_pp_setting"] = "Tilføj ny [\$person_privacy] - indstilling";
$pgv_lang["add_new_up_setting"] = "Tilføj ny [\$user_privacy] - indstilling";
$pgv_lang["add_new_gf_setting"] = "Tilføj ny [\$global_facts] - indstilling";
$pgv_lang["add_new_pf_setting"] = "Tilføj ny [\$person_facts] - indstilling";

Why is it that this only is included in three language files ?,

and why isn't it included in the English language file ?

and when was it entered into the three above mentioned language files ? (I can't recall having entered these lines into lang.da.php) or when was these lines removed from the language files, if that is the case ?

Best regards,

Arne

Another mystery:

Only lang.br.php, lang.da.php, lang.en.php, lang.nl.php, lang.sv.php and lang.tr.php

contain this variable:

$WEEK_START = "0";

Best regards,
Arne

About the "other" mystery: for the NL translation the EN-files are the basis. If a variable exists in that language, we'll translate the text in dutch anyway. But that doesn't explain everything....

Boudewijn

Yes, I also take that the EN-files are the reference, but so much the more surprising it is to find 9 privacy related texts - not present in the EN-file - in three other language files ??? ;-)

Best regards,

Arne

The privacy related messages were moved from lang.xx.php to configure_help.xx.php some releases ago. Don't know when anymore :-(

When I did this I moved the existing messages in all lang.xx.php files into the related configure_help.xx.php file.

Maybe later one of the translators sent a new translated files with those messages inside to one of the developers and he added it to cvs without looking into the file or comparing it with the english one.

That means:
If there are privacy related messages in any lang.xx.php they should be moved from that file to the configure_help.xx.php if they are not inside that file. After that they can be deleted from the lang.xx.php.

The standard content of the lang.xx.php files can bee seen by comparing the file with the lang.en.php.

Only the content of the english language files is actual. Other language files should be edited.

I think the problem was that some translators made translations using the english lang files from the cvs and not from the release packages.

In the future we will try to inform the translators if there are "big" changes on the content of the language files. But every translator should use the compare tool inside the language editor to see which messages were added or removed from each language file.

Now the mystery with the week-start etc. variables inside the language files.

With v2.65.1 those vars are not needed anymore inside the language files because they were moved to the language_settings.php for each language and can be edited with the language editor.

I removed them from the language files today and want to ask the translators to use the new language files. I will put them as a zip into the patches area so every translator can use the newest language files for his translation.

bye, Kurt

Thanks Kurt

Best regards,
Arne

Hi again Kurt

A few additional questions/points:

1. Since the week start variable are moved to language_settings.php, and since it defaults to 0, and since language_settings.php are not translated, it means that everybody now has to change this variable to 1 everytime they upgrade to a new version ?

2. In my opinion you ask to much of the translators when you ask the translators always to use the language files from the CVS. In doing that you basically ask the translators to do the same translations 3 or 4 times and everytime to discard their translations again, because the translations are not checked into the CVS, and isn't part of the release packages! - It is highly contraproductive to discard and redo good translation, and I guess that nobody really like to see their work being wasted !

3. I take that the $DATE_FORMAT = "D M Y"; shouldn't be translated to say "D M Å" ?

Best regards,

Arne

Hi Arne,

To 1:
As I understand the week start it means that every language has its own week start. In Germany the standard week starts with monday. The same in Turkey. It seems that in english spoken countries the week starts with Sunday.

This means that the week start is a fix constant for every language. Si I don't see a need to change the week start. If anybody wants to change this he has to do this for his own.

You are right with the question what will happen after an upgrade with the language settings. This is a point Roland has to think about with the upgrade util. But this was also a problem while the week start was defined in the language files. If a new language file came and you edited the week start manually in the old file you also had to edit the new one manuall, without an edit-tool.
I also ask myself how many admins saw this var before it was made editable inside the lang editor ;-)

To 2:
I think you misunderstood me with this point.
I am NOT a friend of translating language files from the CVS. I think at the end of a beta-phase the translators should get the letest language files to translate them by one of the developers. Then they send their finished work to the same developer they got the files from and this developer should upload the new language files to the CVS.
Everything else could cause double or tripple work. But in the past there were some translators who had a good contact to a developer, took the files from CVS, made their translations and the developer they were in contact with upped the translated files directly to the CVS. If this was done quick, it was ok. If not, problems were generated :-(

To 3:
This is an idea we could talk about. As the bug fixing for a stable 2.6x is the most important work at the moment this could be added in the next future. I am working on the editing of the settings cause I think it is not finished yet. But the new release had to be released to prevent hacking and so I couldn't finish my work as I wanted it :-(
So any more ideas are appreciated :-)

bye, Kurt

Hi Arne and Kurt,

I understand that you are both in favour of a good procedure for the languagefiles. Is it possible to come to some definite agreement with the developers on that?
The only thing I'm worried about it the time, translators get before a new beta or final is released. When translators get the message if it actually IS released, the translations are always one version behind, and everyone has to dowwnload all languagepatches a few days later. Not very admin-friendly!
Boudewijn

Hi Kurt
Yes, you are right: In different cultures the week starts on different days.

In Denmark the week starts on a monday, and since phpGedView defaults to sunday, and since this setting ISN’T PRESERVED, all Danes, Germans, Turks and many other people will have to change this setting during setup of upgrades.

Obviously you can’t find a default which will cover for all, but the problem isn’t so much that this setting has to be changed during setup, if only the setting was available on one of the two basic setup-pages: But in order to change the setting the user will need to find it in an almost hidden corner of phpGedView, where probably only a few of the users ever will come: As a result, the week start probably won’t be changed by far the most users.

So, let’s pray that the week start setting isn’t necessary after all.

I never asked to have the week start variable placed in a language file, but when it was placed in a language file, it guaranteed that the week start would be correct for a particular language once the language was translated, and independent of if the user ever found his/her way to the almost hidden corner of phpGedView and changed the default to the proper value of his/her language.

If I could ask a question here, I would ask, if the user only have to change the setting for his/her language, or if the user has to change the week start setting for all available languages, and if the user is expected to have detailed knowledge of the correct week start in all available languages?

If a user only have to change the week start setting for his/her own language, it means that the week start setting may be right and may be wrong for other languages. Why is it, that this setting must be right for the owner of the site, but doesn’t have to be right for users of another language?

You say that it’s up to Roland and the Upgrade utility to preserve the setting of the week start variable: But if the user never found his/her way to the setting in the first place, there actually are no point in preserving the untouched default.

Not to mention that the upgrade utility is more complicated, confusing and demanding than doing a manual upgrade.

And not to mention that some users only has 5 MB space available at their web host, which again mean that the Upgrade Utility isn’t an option to them.

You said:
> I am NOT a friend of translating language files
> from the CVS. I think at the end of a beta-phase
> the translators should get the letest language
> files to translate them by one of the developers.
> Then they send their finished work to the same
> developer they got the files from and this
> developer should upload the new language files
> to the CVS.

Well, that basically boils down to:
a) You want to get rid of the translators participation in the beta testing.
b) You don’t want to have the bugs exposed, which is found during the installation and setup of the application in the preparation to do a translation, as well as bugs discovered when translators are using the betas in order to see if the translations are proper – that is, you can do a good translation from a text, but you can’t say if it is proper until you have seen it in its context!
c) As to me, I can’t see the point in doing a translation after the application is released. It’s my impression that most Danish users settle with the translations included in the betas or the releases, and never ever fetches any language upgrades from the trackers patches section.

It’s your option if you want to have the translators involved in the beta testing or not, but it’s my impression that even though some of us (like me) are causing irritation, we also help you to a fast discovery of many errors and flaws.

You also said:
> Everything else could cause double or tripple
> work. But in the past there were some
> translators who had a good contact to a
> developer, took the files from CVS, made their
> translations and the developer they were in
> contact with upped the translated files directly
> to the CVS. If this was done quick, it was ok. If
> not, problems were generated :-(


Well, I never had any contact with any developer, but I like to think that I’m generally doing my translations fast – but since the translations never was checked into the CVS and probably wasn’t fetched by anybody, it all amounted to a massive waste of time, except that a few errors, bugs and flaws was discovered in the process.

Finally you said:
> To 3:
> This is an idea we could talk about.

But, this wasn’t supposed to be an idea, but merely a question, if it has to be translated or not.

Best regards,

Arne

Hi Boudewijn,

I agree with you, that the translations needs to be part of the release packages. And it's my impression that Danish users rarely - if ever - fetches updated language translations from the trackers patches section ;-(

To me there would be no point in ever touching a beta if it wasn't for the purpose of translating, and since the translation are not checked into the CVS in the beta phase, and since I won't do the same translations over and over again I simply keep my translated language files and moves them from beta to beta.

I'm sorry, but it looks to me, as if the translations are treated like something secondary, which isn't really appreciated.

Otherwise it would be a little thing for the developers to check the language files into the CVS whenever they want to make changes to the language files, and to ask us to fetch the changed language files again from the CVS.

Best regards,

Arne

Hi Arne,

I still have a positive attitude towards everyone's good intentions. And I still think that we all (developers, translators and testers) want PGV to be a good and improving product.
What I see is thoughts from John for improving projectmanagement, attention from Kurt for the language-editor and files, and many discussions on the fora, all focussed on improving the product and efficiency of making it, including the way developers and translators cooperate.
Nevertheless, the translation-procedure needs a short term solution. I'm convinced the developers will come with some solution to this problem shortly.

Boudewijn.

Hello Everyone,

I understand your frustration with the translations. I am at the other end of those frustrations. It is very difficult to keep up with the all the new patches and updates. PGV is so large now that we have to come up with a new way of applying updated translations. You are right that the translations should not always be a revision behind.

Unfortunately, weI would be waiting weeks if I contacted every language translator with every new release and waited for them to respond to me before making the release.

So, the question is, what to do now? What would be best for you as translators?

Some of my thoughts are:
1. to setup a global language editing area of the PGV website where those who work on the translations are given their own username and password so that they can work on the latest files from the CVS and so that I can always have the latest files when I get ready to make a new release. The big downside to this is that it is a major development endeavor to set this up and get working.
2. Another option that I have thought of is those languages that have active translators would be allowed to have 1 or 2 translators on the PGV developers list so that they can work directly with the language files from the CVS and commit the changes to the CVS without having to do any uploading to the patches area.

What do you as translators think would be best? I will do what you want. What other ideas do you have? What else should I be doing to help you? What else should we all be doing to help the PGV users?

Thank you all for your patience as PhpGedView goes through these growing pains to get to the next level. We are all aware that PhpGedView is the best way to share your genealogy on the Internet. Going to this next level is going to take a lot of work from all of us. I never imagined that PGV would become a peer among projects like PhpMyAdmin or phpBB. But it is time that we all--especially me--accept the great potential of PhpGedView. This is a potential that I am reluctant to accept because of the work that it is going to require from me and because I question my abilities as a project leader to make the project meet its potential.

The expectations and the stakes are high. I pray for the help and strength to meet them.

--------------------------------

Now for some explanation about the new language_settings.php file.

The WEEK_START variable is now a part of the $language_settings array in the language_settings.php file. Other variables that used to be in the lang files but are now in the language settings are the DATE_FORMAT, TEXT_DIRECTION, NAME_REVERSE, and sorting ALPHABET_lower and ALPHABET_upper. These variables were not present in every language file so when they got added to the language settings array they were set to the default value for english.

The value of these variables in the language settings array should be set to the default for the language. As Arne says, every user should not have to set these language specific variables for their site. But some of these defaults did not get set properly in time for the 2.65 release, for which I am sorry.

The purpose of the language settings is to make it easier for you as translators to adjust the settings for your language and eventually add new languages. It will also allow site admins the ability to turn off certain languages if they don't want to use them on their site.

I will release an update to version 2.65.2 in the next few days. No new languages or functionality will be added to this release, just updates. Language updates included. Please let us know what default values you would like to have set for your language.

When you update your langauge files you should also update the language_settings.php file.

Thanks,
--John

Hi John,

Thank you for your understanding of our difficulties and suggestions for improving the way we (all) work.
As mentioned before, PGV is not an ordinary IT-project, with a projectmanager and people doing work-packages on the project. It's a more cooperative form of organizing things, depending largely on mutual commitment. People are not given responsibility, they take it, out of free will.
For a larger project of this kind, it means much agreeing on things and communication about what happens, more than in a "normal" project. Roles are less dinstinguished and another responsibility we have is to help eachother. In other projects, the PM decides what happens, here it's more discussion and giving ideas. And that's what I like about this.
My thoughts about how to handle translations follows directly from the above. First of all, someone (one person) has to be responsible for a translation in a language. If not, it's impossible to agree on procedures. Secondly, he/she is free to organize that in a way that suits him/her best. Here in the Netherlands we try to cooperate in translating, the actual work as well as reviews. I think it may be in the role of " PGV-Translator" too, to organize and coordinate that, outside the view of the PM.
Feet on the ground again: your suggestion 2. is the most likely to work in my opinion, because it fits best on the role of "PGV-translator". I imagine every language will have such a person (only 1), who will somehow take care of the translations, (just) in time for new releases. Other advantages are: a limited number of translators has access to the CVS and communication is only neccesary to a limited number of known persons.
As for the dutch translation, I volunteer to take care of that.

I think this is a first step forward to organizing the project in a way, fit for it's size and complexity. If this works out, perhaps we can look at other aspects too, like testing and prioritizing RFE's.

Boudewijn.

Hi Everyone,

Option #2 seems to be the direction that we are going. Which is probably best. We can give it a try and see how things go. Boudewijn, I will add you to the developers list as a translator.

Arne I would also like to invite you to join the developers list as a translator.

I have already added Peter Pluntke to handle the German translation and help with the website. I will try to contact some of the other language translators and invite them as well. Most of the other languages are not as active as you.

Thanks for all of your help,
--John

I volunteer to be the Swedish translator. I have done the translations since version 2.52.

Regards
Patrik

Hi John

The preferred settings for danish would be:

//-- settings for danish

$lang = array();
$lang["pgv_langname"] = "danish";
$lang["pgv_lang_use"] = true;
$lang["pgv_lang"] = "Dansk";
$lang["lang_short_cut"] = "da";
$lang["pgv_language"] = "languages/lang.da.php";
$lang["confighelpfile"] = "languages/configure_help.da.php";
$lang["helptextfile"] = "languages/help_text.da.php";
$lang["flagsfile"] = "images/flags/da.gif";
$lang["factsfile"] = "languages/facts.da.php";
$lang["DATE_FORMAT"] = "D M Y";
$lang["WEEK_START"] = "1";
$lang["TEXT_DIRECTION"] = "0";
$lang["NAME_REVERSE"] = false;
$lang["ALPHABET_upper"]= "ABCDEFGHIJKLMNOPQRSTUVWXYZÆØÅ";
$lang["ALPHABET_lower"]= "abcdefghijklmnopqrstuvwxyzæøå";
$language_settings["danish"] = $lang;

When that is said, it must be added that I probably need to expand the Danish alphabet with German and French characters as well, because older person and place -names sometimes are in German and/or French ;-(

But for now the above settings will have to do ...

As to your option #2, it sounds like a good solution, and thanks for inviting me to join the team: I'll gladly accept :-)

Best regards,
Arne

John,

OK, thnx!

Boudewijn.

Arne and Patrik,

Welcome to the Developers list. ;-)

You will want to follow the discussions in the Developers forum. That is where any plans to change the language file settings will be discussed before bringing them to the translators forum.

Thanks,
--John