Closed Albino-Zoe closed 1 year ago
You should try to use Git, clone the repo, make all corrections and then make a merge-request. :-)
German translations have been merged from 3 sources, so I did not pay attention on this while merging. But you are right, different names for the same things should be avoided.
Hi, I know ... open source ;-)
but also the English names are sometimes different :-(
If I knew so well in Canze know that I can say what each value means, then I could also say to 100%, if it are the same values ... but in the moment I can not do that ;-)
I am sure there are enough experts who can correct this very quickly or make comments :-)
Hello,
Please do not use the file "Matrix_Werte_CanZE_1_22.xlsx", there are some faults. I have solved my questions based on V1.24 myself :-) The following values have different names and should be unified because they represent the same value in other screens.
Remark: [xx] The measuring unit is behind the value and not in the name
English:
Screen: BATTERY Value: Real State of Charge (%)
Screen: CHARGING (Main) Value: Real state of charge (%)
Screen: CHARGING (Technical) Value: Real state of charge (%)
suggestion: Real state of charge (%)
Screen: BATTERY Value: Battery Modules Temperatures (°C)
Screen: CHARGING (Technical) Value: Battery modules temperatures [°C]
Screen: TEMPERATURE HEATMAP Value: Battery modules temperatures
suggestion: Battery modules temperatures (°C)
Screen: CHARGING (Main) Value: Available Charging Power kW
Screen: CHARGING GRAPHS Value: Charger power (kW)
Screen: CHARGING PREDICTION Value: AC power [kW]
suggestion: Available charging power (kW)
Screen: CHARGING (Main) Value: DC Power kW
Screen: CHARGING (Technical) Value: DC Power kW
Screen: CLIMATE Value: DC Power kW
Screen: CHARGING GRAPHS Value: DC Charging power (kW)
suggestion: DC charging power (kW)
Screen: CONSUMPTION Value: Range (km)
Screen: CHARGING (Main) Value: Available range
Screen: CHARGING (Technical) Value: Available range
Screen: RANGE Value: Available distance (km)
suggestion: Available distance (km)
Screen: CONSUMPTION Value: State of Charge (%)
Screen: CHARGING PREDICTION Value: State of charge [%]
suggestion: State of charge (%)
Screen: CHARGING (Technical) Value: Max AC charge pilot Amp
Screen: CHARGING GRAPH Value: Pilot amp (A)
suggestion: Pilot amp (A)
This pleases me if you have the same opinion. Then the correction should begin. The adjustment in German is quite easy to do then.
I' d like to support you.
Here we try to find a solution:
I'll be back ... hopefully soon ;-)
I have tried to group the xml entries on a per screen basis but the language editor, which is a great help, will not maintain that, and string resources are simply appended at the end. Maybe we should let go of that plan.
Do you want to finish the topic completely or only the planned procedure? I know, here https://www.goingelectric.de/forum/viewtopic.php?f=57&t=22468&p=934006#p934006 also missing a final answer :-(
I'm not a programmer / developer :-( I also have not understood yet, where are these information to be found in the appropriate language? In source code somewhere or per language in an extra file?
Thanks for the link. I am not the only developer but let me be completely frank on this one. Accept my apologies if I seems to sound rudely Dutch ;-)
The issue of the wording is absolutely valid, but also has a low priority. It doesn't hamper functionality at all and the people actually working on it tend to put there focus there. This is why I kept the issue open. I think we agree that this is a different issue than just unequal wording for the same field.
the comments in that thread rub me the wrong way. If somebody thinks things need to be done, well, the always hated open source argument: step in and so something. And if those somebodies don't like me or Bob executing their holy wishes, well, too bad. We see a lot of nonsensical or out of scope or not very interesting requests/demands. This is not directed at you, you put in detailed comments, thank you.
Most people willing to step in for translation do only one shot translations but the then files are orphaned. For me personally, I will maintain the English and the Dutch version and that's it.
The language file for German is here: https://github.com/fesch/CanZE/blob/master/app/src/main/res/values-de/strings.xml . The English one, which is leading, is here https://github.com/fesch/CanZE/blob/master/app/src/main/res/values/strings.xml . Best thing is to make a clone and put in merge requests, but I really understand using git can feel intimidating and therefor I am happy to accept a bare XML file and simply replace that in the source, no problem, and always appreciated.
Most of the comments done in English and Dutch, some of the German already in commit #2deb082. I propose to close this issue. It is a continuous process and I think it is wise to have permanent language owners with an established update process and ditch languages for which there is no owner. Calling @fesch for extra opinion.
I am happy to adopt English and Dutch, but I would prefer somebody else. Never good to assess your own meat.
Everyone may have his opinion: Mine is, that such apps should be always in English, so please forgive me if I'm out of all this.
I support multi-lang support for those of you willing to provide translations, but I will neither do some, nor use some ...
I tend to agree and it's in line with above suggestion to either have a owner, or ditch altogether. Let's wait a few days because of the latest release, then put a request-for-owners up the blog and ditch the languages that are not taken up in say two weeks.
We could put out an extra item on goingelectric.de and forumpro.fr. For the Dutch I will ask in the local forum. I would not be surprised if nearly nobody used it, in which case I will most certainly ditch that one.
We could then focus more on consistent language / capitals / etc use, which I do believe is a valid point.
Leaving this open then until we decide
Quick poll in the Dutch forum showed no more than lukewarm interest in the ongoing translation. The few answers I got were along the lines of "EN or DE is fine. NL is kinda cute, but not if it eats into development stuff". The numbers might not be very representative and the Dutch, given the language is tiny, are in general OK with English in apps and stuff.
Hi, I just brought up the question in the french forum (http://renault-zoe.forumpro.fr/t13655-traduction-francaise-de-canze) Since some see value in having french translations, and are motivated to help, we will try to organize ourselves to maintain the french translations.
I will have a closer look to see how much work it is. Hopefully I should be able to submit pull requests for modifications in the french translations file...
Hi Cedric, that is appreciated. The French file is locate here for peeks
https://github.com/fesch/CanZE/blob/master/app/src/main/res/values-fr/strings.xml
Cedric, I saw your last post in the french forum. I have no problem sending out a warning if a release is imminent, and Android Studio (or almost any decent git client) has very good diff features.
Dear @cedricberger @Albino-Zoe I noticed that the threads on your local forums went quiet. Being the impatient guy I can be I was wondering if you think you or one of your forum members could be the committed maintainer for French and German (by far the biggest user group) respectively. It is not hard to do, but to make it work it would need:
From my end (and I think @fesch would agree), I am willing to give notice a few days before a release, and help out getting into the flow of a pull- change - commit - push - merge request.
Ok, I am willing to be the commiter for the french translations.
For now what I am trying to figure out, is how I could do to easily collaborate with others (from the french forum), to be able to review translations together. But this is not a showstopper anyway.
That is great, thank you!
Best way to process is to make a fork from the project, switch to the development branch, always pull the latest commits in from the main project (I promise from now on I won't touch the .fr XML file so you should have no merge conflicts), make changes, push hem to your fork and then request a merge. It sounds complicated but it's really easy once you get the hang of it.
As for collaboration: the ideal model in my opinion would be for them to do exactly the same with you fork, but that is probably massive overkill ;-)
I submitted a pull request for the french translations! Let me know if it is OK... If possible, keep the 2 commits (not squashed), since one only refactors the declarations (removed comments, same order as English file), the other makes the actual modifications.
@cedricberger Nice, thank you!
@Albino-Zoe any progress re. the German contributors?
I think we need announce ditching Slovenian. There are less than 30 users if I didn't misinterpret the play store console.
Placeholder for changes impacting language files in the next release. I'll edit this while working on changes.
Many unused resources are removed New activity All Data BCB activity removed and functionality moved to Chargingtech and header_ChargerKeyParameters changed to header_GridParameters Query DTCs shortened for 3 column layout Elm Dump removed LeafSpy refactored to Dash
Hi @cedricberger . We plan on doing a release in a couple of days. Could you maybe pull the development branch to your fork and have a peek at the things I mentioned above? It should really only be a few lines. Thanks!
@Albino-Zoe : I put a nudge in the thread you referred to on goingelectric, on the home page of the blog, and on the news bar of the latest release, but no takers. With Germany the biggest user group (from memory about 25%) it would be a shame to drop it. BTW, same is true for Spanish.
OK, I pushed small changes to the french translations.
Thank you!
@yoh-there: You mean in this post "https://www.goingelectric.de/forum/viewtopic.php?f=57&t=22468&p=934006#p943661" ?
@Albino-Zoe Yes sir, it was intended as a "nudge" to the group of people who seem to be genuinely interested in proper language to come to this thread, notice the stances and possibly consider if they want to take on the task. Of course in addition to the message on CanZE's main screen right now and the official website.
I have news. The two users who have been interested in the last few years do not drive Zoe anymore :-( I still try to take a look at the translation and with your support we get that corrected once
@Albino-Zoe Ah, fair enough and thank you for that info. FYI: nobody else stepped up. I think we are in reasonable shape now, but without a dedicated maintaines, the quality of the translations will go down, either by English words creeping in, or "Google translate" like translations, so I envisage a drop of ES and DE language support over time. There is no need to -do that in haste though.
Thank you VERY much for your effort and involvement. It is truly appreciated. / Jeroen
Placeholder for new string items, in this case all moved from hard coded strings; there is in effect nothing new. tags:
toast_AdjustSettings format_NoSid format_NoAsset message_DumpDone format_DumpWriting default_Reset message_CantConnect message_HardResetFailed message_ELM13Ready message_ELM14Ready message_ELM20Ready message_ELM8015Ready message_ELMReady message_ELMUnknown
@cedricberger I am going to propose a release soon. In the meantime I have have moved some hard coded English strings to the resources. If you can, could you please pull the current development and have a peek at the missing French ones? Thank you!
@PeBueGo tagging you in this thread. I think you have all the open ones done.
As there are no takers for the Spanish translation, I will start announcing deprecation of the Spanish language support on June 1st on the news bar and on the blog, with actual deprecation around August 1st.
To all translators:
1) With the removal of Kangoo / Fluence support, I have removed the unused keys / translations. If you want to make any changes to the files you manage, please pull the changes I made in the development branch first please.
2) I would appreciate a translation for "Not OK".
Thanks!
@landswellsong
What's the context for that string? Generally if you want to preserve visual dimensions, it would be "Не ОК" (I've typed in Cyrillics) for both Ukrainian and Russian.
On a very unrelated note (but following pt.1), a local EV repair shop complained recently about the loss of Kangoo/Fluence, they always have cars on their hands and can do the testing, is there any way the support could have retained or should I just keep a fork for them?
The context is something like: Tyre mismatch: OK / Not OK.
I would recommend FluenceSpy by Alexandre Moleiro. If that doesn't fit, please open a new issue where we can discuss what the issue is in detail.
Right, «ОК» / «Не ОК» would be understood. There are more book variations literally «in norm» and «in order», but I'm afraid they will be visually longer, so I think the first one is the way to go.
All, Could you please supply me with translations (FR/DE/UK/RU) for
Thanks
I can't submit a pull request right now, but the FR translations would be:
Thanks. I entered it in the development branch.
Sorry I have to monitor this thread time to time I guess.
UK
RU
I've not updated the app yet, though, if Dark Mode means "mode you activate when it's dark around you" and not just other color scheme, then substitute Темний for Нічний/Ночной (UK/RU), which means "Night", should be much more understandable I guess.
Thank you, I will put those in. You don't get an email when this post is amended? Hmmm.
if you are going to check once in a while, maybe a better option is to make a fork here on github, merge now and then, check the two relevant strings.xml files, and issue a pull request. I try to add new words to the language files but keep them in English so they are easy to pick up.
But if there is a way that wrks better for all of you, let me know.
I probably have, I just recently started working with an organisation that has their codebase on GitHub so the inbox is totally busting over there. If you could tag me that'd be really great.
We now have active DE and FR native speakers in the team. A lot has changed though since adding Ph2 support. If anyone wants to pick UK and RU up, we are open to PR's as always. Thank you!
@yoh-there on my way, should it be against master
or Development
?
Development I bet ;-)
Yup. But hey guys, it's Christmas eve? Oh wait :D
@yoh-there it's only Christmas here since a few years so we're not really celebrating :P
Hmm guys is there a reason for this being untranslated? https://github.com/fesch/CanZE/blob/master/app/src/main/java/lu/fisch/canze/activities/SettingsCustomActivity.java#L37
It seems that the manifest implies the title_activity_settingscustom
string here, so I'll patch it up in my localization PR but feel free to stop me if it's not a mistake.
No no, you're right! Thanks for spotting,
More questions:
I have no solid answers to these questions. In essence, these descriptions came from the web. Often, they seem to be a bit "Frenglish" too. And then I don't own a ZE50 / am not very into the technical changes they did. So below is my guess only....
Okay, now at least I don't feel like I'm missing something obvious that every EV enthusiast was supposed to know :D
As to (3), I'm really curious. We have a lot of bad chargers in Ukraine in the Red Nose of Death sense. If bad ground was the completion status it would have been shown in such instances I guess, but I'm not sure I saw anything like that there in CanZE. Maybe those errors are more related to phase voltage skew, hmm.
Hello,
it would be possible for you to look at the created table? Matrix_Werte_CanZE_1_22.xlsx
I have selected from all screens which values are displayed and in which way. It appears that sometimes a slightly different name may have been chosen for the same value. This can be confusing. I think it's good if it's always the same name. Do you also see it like that?
For example (Refer to the table for details on the screen name):
No.2 Echte Kapazität (SOC) (%) -> Real State of Charge (%) No.3 Echter Ladestatus % -> Real state of Charge (%)
No.6 Temperatur der Batteriemodule (°C) -> Battery Modules Temperatures (°C) No.7 Temperaturen -> Battery modules temperatures [°C]
No.12 Mögliche Ladeleistung kW -> Available Charging Power kW No.13 Ladeleistung kW -> Charger Power (kW) No.14 Wechselspannung [kW] -> AC power [kW]
No.17 Gleichstromleistung kW -> DC Power kW No.18 Gleichstromladeleistung (kW) -> DC Charging Power(kW)
No.19 Reichweite (km) -> Range (km) No.20 Verfügbare Reichweite -> Available range No.21 Verfügbare Reichweite (km) -> Available distance (km)
No.39 Kapazität (%) -> State of Charge (%) No.40 Ladezustand [%] -> State of charge [%]
No.48 Max AC Ladestrom Pilot Amp -> Max AC charge pilot Amp No.49 Pilotsignal (A) -> Pilot amp (A)
Perhaps it is also partially a different value, I'm not sure, I'am a "Newbie".
I would find this table also generally useful, maybe you want to use it for the HP ? Here is also the option to add, which values are currently displayed in the car. This creates clarity, which values are only displayed so far in the car and what CanZE additionally displays.
Last but not least the reference to a few small writing errors, etc.
screen Consumption: Power (kw) -> Power (kW)
screen Climate: Kühlungsstatus Tracktionsbatterie -> Kühlungsstatus Traktionsbatterie screen Climate: Compressor RPM -Translation-> Kompressor UpM screen Climate: Kühlungmodus der Traktionsbatterie -> Kühlungsmodus der Traktionsbatterie
screen Charging: Energy consumed kWh -Translation-> ??? (bisheriger Akkuverbrauch)
screen Charging Prediction: AC power [kW] -Translation-> Wechselspannung [kW] ???
KW is the unit of measure for power, but the German word "Wechselspannung" describes only the abbreviation AC. "AC Leistung [kW]" should be the correct translation.
I am looking forward to feedback.
Zoe Intens R240 (25.08.2016) 25.000km/Jahr CanZE (Android) (V1.22) mit KW902 ELM327 (27.01.2017)