Closed Akkell closed 7 years ago
It happens because LocoLaser thinks that the Sheet was not changed. If you look on the logs you will see the message "Source have not been changed since the last import. Only modified resource files will be refreshed.". For some reason Google API returns date of the last update with delay.
This is not the case. There is another line: Source was changed. All resource files will be refreshed.
Executing tasks: [localize]
Configuration on demand is an incubating feature.
Incremental java compilation is an incubating feature.
The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use Task.doLast(Action) instead.
:mobile:localize
Reading config file C:\Users\...\mobile\localize_config.json
Open sheet: Sheet name
2 worksheets found.
Searching worksheet with title: mobile
Worksheet found.
Source was changed. All resource files will be refreshed.
Title row: 2
Value not found! Locale= ru, key= app_name.
...
Total time: 5519 millis.
:wear:localize
Reading config file C:\Users\...\wear\localize_config.json
Open sheet: Sheet name
2 worksheets found.
Searching worksheet with title: watch
Worksheet found.
Source have not been changed since the last import. Only modified resource files will be refreshed.
Resource file for locale "ru" have not been changed since the last import. Ignore this file.
Resource file for locale "uk" have not been changed since the last import. Ignore this file.
Resource file for locale "base" have not been changed since the last import. Ignore this file.
Nothing to update. Localization stopped.
Total time: 3129 millis.
BUILD SUCCESSFUL
Total time: 10.735 secs
@Akkell it's strange behawiour. It can be happened only if you use the same temp folder for both modules or you did run task ":wear:localize" before task "localize". Is this so?
The log above is produced in response to run :mobile:localize
(I didn't run :wear:localize
explicitly).
But the issue was present even before :wear:localize
existence. (before LocoLaser integration with wear
module)
I didn't override any temp folder settings, so they should be different. I ran :wear:localize
before, but not during any steps of issue reproduction.
So. Let's summary. In the logs that you did post we have 2 tasks. 1-st task run ok. Second task do nothing because you already run it before. Both tasks run independently. It's ok.
Also, probably you run only one task by clicking on task in the tasks list. It's bug in Android Studio. It shows task name :wear:localize
but run task localize
.
Bug described in the topic reproduced if you run localisation many times with short delay. It happen because Google caches response when LocoLaser request the date of last modification. I don't cnow how to fix it right now. Let's leave this issue open yet.
Bug reproduces even if I run localization one time after ~12h delay with the following steps:
localize
(after ~12h delay from previous time on this PC). Look at strings.xml files.
Expected: string resource removed
Actual: in all strings.xml files, string resource moved to the top of <resources>
section.If Google return cached response, there should be no changes to strings.xml files, right? But they are.
I found the reason. I should read carefully the description of the bug. You put conflict_strategy
in the wrong place. You should put it in to root node.
I think I should add more informative description in ReadMe.
You are right.
Tested with "conflict_strategy":"remove_platform"
in the config root - everything works. But with delay caused by GSheet cache you described.
As for ReadMe, it may be more clear to have a full config example, like in Android manifest guide.
ReadMe fixed
Platform: Android
Steps:
"conflict_strategy":"remove_platform",
to thesource
node of config file.key1 value1
to GoogleSheet.key1 value1
from GoogleSheet.<string name="key1">value1</string>
instrings.xml
.Actual result:
<string name="key1">value1</string>
is present at the top of<resources>
section. (After step 3 it was in the middle of the<resources>
section) Expected result: no such line.